This module “intercepts all outgoing emails from a Drupal site and reroutes them to a predefined configurable email address”.
In other words, if you want to send a test email that doesn’t actually make it to users, the Reroute Email module gives you an easy way to do it.
Rabbit Hole lets you control how content types are displayed on their own page.
For example, if you have a certain content type that should never be displayed on its own page, you can use Rabbit Hole to display an Access denied message should a user attempt to access its node.
Save time and cut down on coding whenever you need to create a custom page. The Config Pages module lets you create rich page types that your content editors can easily modify via custom fields and drop-downs.
Drupal’s Mailgun module provides integration with the open-source, developer-focused Mailgun email service. The service, which “uses REST APIs to effortlessly send, receive and track emails”, is a mainstay in our team.
“If I need to send emails, this is my go-to.”
– Ivan Doroshenko, Evolving Web developer
If you’re creating a new Drupal 9 site, this should probably be the first module you install. Admin Toolbar lets you access all of Drupal’s admin pages via a convenient mega-menu, saving you countless clicks.
The Pathauto module helps you keep your URL aliases clean and consistent by automatically generating them according to your desired parameters.
Never worry about forgetting a redirect again. If a content editor changes a page’s URL alias, the Redirect module will automatically implement an appropriate redirect.
If you’ve ever been disappointed by the way a piece of content looked when you shared it on social media, this must-have module is for you. It lets you customize things like image format and description text across various social media snippet types, so your content looks the way you want it to whether it’s being viewed on Twitter or on Facebook.
The last 18 months have been difficult for many in our global community. The global COVID-19 pandemic has taken loved ones from us too soon. Social and political upheaval around the world have fractured civil discourse, and set back the cause of civil rights. Economic uncertainty has affected our jobs and our prospects for the future. For some, the present crises have brought up memories of more distant loss.
In a year in which we have all experienced loss, remembrance and reflection helps us heal.
We encourage the Drupal community to share memories of lost friends, colleagues, family, and loved ones- whether that loss was recent or many years past. We encourage you to share and remember the good they brought to our lives.
We encourage you to share your words of hope for civil and societal change.
Whatever your words of hope and remembrance we encourage you to lift each other up.
How to share your words of remembrance: The comments on this post have been opened, or you can use the hashtag #drupalmemorial on social media to tag your posts to the embedded memorial wall below
The past year has been a busy one for the Drupal Community Working Group (CWG), as we created a new “Community Health Team” and saw the stepping down of the last original member of the Conflict Resolution Team, George DeMet. As the CWG enters its 8th year, we feel it is our duty to continue to pursue our mission to “foster a friendly and welcoming community for the Drupal project and to uphold the Drupal Code of Conduct”. With this guiding principle, we have been focusing on both proactive and reactive tasks to help us achieve this goal.
This annual report will serve as a summary of what we’ve accomplished over the past year, as well as a discussion of some of our goals for the near future.
Community Health Team
The Community Working Group was expanded during the first half of 2020 with the creation of the Community Health Team. The mission of this new team is to focus on proactive community health tasks including workshops and knowledge transfer. With the help of Tara King, the CWG membership coordinator, we structured the team into several groups. Although team members may do work across multiple groups, each of these groups is designed to, but not limited to, focus on a specific area:
Community Event Support – provide resources and support related to the Code of Conduct for Drupal events.
Community Health – provide opportunities to educate and train community members to be more effective contributors.
Membership – to help identify and recruit community members for the CWG.
Ambassadors – provide expertise and advice related to geographic, cultural, and other differences both inside and outside the Drupal community.
Community Health Team members are not privy to Code of Conduct incident reports; however they must adhere to the CWG Code of Ethics.
Once the team was created and volunteers were found for the majority of the roles, we began having monthly meetings during the second half of 2020. The team has already completed a number of tasks including:
Initial work on a Drupal Code of Conduct update.
Documentation of CWG roles.
Development of a group of community health representatives from other open source communities.
Ongoing Code of Conduct contact workshops.
Updates to the Drupal event Code of Conduct templates and playbook.
Ongoing Mental Health First Aid workshops for community members.
Blog posts related to community health.
“Nudges” for Drupal Slack Workspace and issue queues.
Other, long term goals for the Community Health Team include providing an on-ramp for the Conflict Resolution Team and identifying and presenting additional community-health-related workshops for the community,
Conflict Resolution Team
After six years on the Conflict Resolution team, including several years as its chair, George DeMet retired from the team at the end of 2020. We cannot understate how much of an impact George has had on the CWG and the Drupal community, often working behind the scenes. We are fortunate that George has agreed to stay on as a member of the Community Health Team where he will be focusing on updating the Drupal Code of Conduct.
During 2020, in addition to the creation of the Community Health Team, the Conflict Resolution Team continued to work on on-going and new Code of Conduct related issues. During our weekly meetings, we generally work on three types of tasks:
Internal business – examples include recruitment, public blog posts and presentations, Aaron Winborn Award, event organizer requests.
External, old business – ongoing conflict resolution tasks normally brought to us from community members.
External, new business – new conflict resolution tasks, normally brought to us from community members.
While some conflict resolution tasks can be resolved quickly (a few days), we normally have several long-term, on-going issues that can take anywhere from weeks to months to resolve. Most of the long-term issues include ongoing personality conflicts within the community, but we also routinely work with community members who had previously had their community privileges limited on plans and tasks to have those privileges restored (see our Balancing Accountability and Compassion in the Drupal Community blog post).
What types of conflict resolution issues do we work on?
We decided to perform a quantitative analysis of the number and types of conflict resolution issues we work on, comparing data from 2019 with 2020. Our methodology allowed us to assign one or two of the following categories to each new issue we received during 2019 and 2020:
Social media conflict
Issue queue conflict
Drupal Slack workspace conflict
In-person Drupal event conflict
Virtual Drupal event conflict
Not CWG domain
Other – examples include content issues on Drupal.org, issues related to local Drupal communities (but not directly related to an event), interpersonal issues occurring in areas not covered by any of the other categories.
In terms of overall number of incidents, while 2019 had 35 total new reported incidents to the CWG, 2020 has slightly less than half of that, with 17 new reported incidents.
While the number of incidents occurring at in-person Drupal events dropped from six in 2019 to none in 2020, this doesn’t account for the entire reduction of total incidents between 2019 and 2020. We also saw fewer social media and Drupal Slack workspace conflicts, but the biggest drop was in the “Other” category, which saw a decrease from ten incidents in 2019 to just two in 2020.
Obviously, the drop in in-person incident reports is directly related to the pandemic.
What else can we attribute the dramatic drop in incident reports to? We hope that the formation of the Community Health Team is having some effect, but we’re not so naive to attribute the entire decrease to its creation and actions during 2020.
Total number of new reported issues
Social media conflict
Issue queue conflict
Drupal Slack workspace conflict
In-person Drupal event conflict
Virtual Drupal event conflict
Not CWG domain
Conflict resolution team membership
One of the primary goals of the conflict resolution team in the first part of 2020 was expanding the size of the team. With the recent departure of George DeMet and the decrease in our workload (thanks to fewer incident reports and the amazing work of the Community Health Team), we decided this was a good time to recruit new team members.
We had six amazing community members approach us about joining the team, and will be inviting a new member(s) to the team in the next few weeks. One of the main goals of the Community Health team was to provide an on-ramp to the Conflict Resolution Team. Those community members who were not extended an offer to join the Conflict Resolution Team will be asked to join the Community Health Team in a capacity of their choosing, if they haven’t joined already.
As part of the process of having new members join the team, we implemented (and are in the process of documenting) a new on-boarding process, where new team members are considered “trial members” for a maximum of 5 months. During this period, new members will mainly shadow the team and have limited access to historical conflict resolution reports. At the conclusion of the trial period new members will either become regular members or be asked to leave the team. As is prescribed by our charter, all trial members must be approved by the CWG Review Panel.
Community Health Team
Now that our Community Health Team is a year old and has some experience under its belt, we have high hopes that they will continue to be a force for good in the community. Our plans for the next year include finding and presenting additional workshops, completing the aforementioned Drupal Code of Conduct update, and assisting with the expansion of the yet-to-have-a-good-name group of community health volunteers from various open source communities.
Read our roadmap to understand how this work falls into priorities set by the Drupal Association with direction and collaboration from the Board and community. You can also review the Drupal project roadmap.
Drupal’s 20th Birthday Year
As we close out the first quarter of 2021, we continue the celebration of 20 years of Drupal with #DrupalFest and #DrupalCon!
#DrupalFest is a month-long celebration of all things Drupal, taking place online all around the world. DrupalFest lasts throughout the month of April. Most events are free, and we encourage everyone to attend, and even submit your own!
DrupalCon is right around the corner from April 12-16, happening online. This year’s DrupalCon reflects a renewed focus on the strategic initiatives that drive innovation in Drupal. Each day has a half day of live programming for and then a half day of contribution, and all personas are welcome! Join us!
Increased focus on Strategic Initiatives
Speaking of strategic initiatives, the current primary initiatives being highlighted at DrupalCon and beyond are:
Easy out of the Box – This mega-initiative combines the efforts of Layout Builder, Media, and Claro to help empower content editors in Drupal to take advantage of the best that Drupal can offer.
Automatic Updates – This initiative is focused on the #1 most requested feature in Drupal: automatic updates. The initiative is building a robust and secure system for automatically updating Drupal, starting with security and patch releases.
Drupal 10 Readiness – The Drupal innovation train keeps rolling! The Drupal 10 Readiness initiative is rallying the community around what we need to reach our Drupal 10 release date, and helping site owners ensure they’re ready for the upgrade when the time comes.
At DrupalCon North America the Decoupled Menus initiative leads invite you to a hackathon to begin to create applications for this work.
The rapid movement on this initiative shows how quickly the Drupal community can pivot into more robust and standardized Decoupled implementations, and furthers Drupal’s lead in the marketplace.
Easy Out of the Box Support
For the Easy Out of the Box team, the Drupal Association has been focused on connecting the initiative leads to the Drupal Contribution Mentoring team, so that at DrupalCon there will be a variety of onramps to help new contributors support this work.
Easy Out of the Box is effectively three initiatives in one, focused on Layouts, Media, and the Claro administrative theme, so people with interest in any of those areas are more than welcome.
The Drupal Association Engineering team continues its close collaboration with the AutoUpdates initiative team. Because AutoUpdates requires a server side component that will live on Drupal.org infrastructure, the engineering team needs to be closely involved.
This initiative has also had a heavy focus on cross-project collaboration – with three CMS partners in the PHP ecosystem collaborating together on the basic principles of supporting securely signed update packages.
We’re also collaborating with other partners, such as the Cloud Native Computing Foundations ‘TUF'(The Update Framework) team, and the team behind Composer.
At DrupalCon North America the TUF team will be presenting about securing software package delivery – a topic that is sure to be interesting for all.
Drupal 10 Readiness Support
Drupal 10 is slated for release in June of 2022, which is only a little bit more than a year away. Fortunately, Drupal 10 follows the continuous innovation model of Drupal development that was so successful in the transition from Drupal 8 to Drupal 9. In essence, so long as site owners are up to date with the latest version of Drupal 9 they should be able to make the jump very easily. The only area of concern is deprecated code.
To that end, the Drupal Association engineering team collaborated with Gábor Hotjsy to set up automate code deprecation checking using the DrupalCI infrastructure. This allows the team to understand the most used instances of deprecated code, so that contributed module maintainers can be made aware of the need to update, and so that the Drupal Rector team(supported by Palantir.net) can begin creating automatic deprecation patches.
GitLab Merge Request Updates
Last year, Drupal.org migrated our community contribution tools to GitLab, by integrating the existing Drupal.org issue queues with GitLab’s merge request functionality.
Thanks to these improvements, the complete contribution lifecycle can be completed entirely in the browser. As a contributor to Drupal you no longer need to use command line git, install a local development environment, or use a local IDE in order to make your contributions.
Since the initial launch, we’ve received feedback from many people in the community about improvements to usability with the Drupal.org issue queue integration. Looking at the child issues of this issue, we can see rapid usability improvements that have sped the pace of contribution.
More recently, we worked with our partners at Tugboat.qa to release live deployment previews of your code changes – first for Drupal Core, but now available for contributed projects on Drupal.org as well. This means that even reviewing visual changes or seeing your code deployed to a site can all be done without leaving your browser. This is a huge boon to all contributors, but especially to usability and accessibility experts who can much more easily view the impact of changes across issues.
Major improvements to Community events
In collaboration with the Events Organizers Working Group, the Drupal Association has updated the Drupal.org Community Events section. This new section represents a central repository for all of the events taking place across the Drupal Community, and will ultimately be the replacement for Groups.Drupal.org.
This section allows anyone in the community to submit their events, whether online or in-person, and provides a variety of views to help people find events they’d like to attend. Events can be filtered by type(con, camp, meetup, training, etc); proposed events can be submitted to help avoid scheduling conflicts; and calls for content/speakers can be promoted.
A feed of these events is made available for 3rd party tools built by the community, which is already being used to feed Drupical.com.
Led by community volunteer u/jhodgdon, Drupal.org’s documentation tools have seen a variety of updates. In particular, the Drupal contributor guide is now much more complete, helping folks who are new to contribution in Drupal find a place to fit in and get started.
We’ve also deployed improvements that make it easier to understand whether the documentation you’re reading is up-to-date, and how to report problems if you find them.
If you’re looking for somewhere to contribute – helping to update documentation is a wonderful place to start!
Coming soon: Discover Drupal Portal
Coming up at DrupalCon is the announcement of a new program: Discover Drupal. This program is part of the Drupal Association’s talent and education initiatives, and represents the Drupal Association’s commitment to growing the Drupal talent pool and increasing diversity in our community.
With the official announcement just around the corner we won’t spoil the details here, but very soon you’ll be able to check out the new web portal for the Discover Drupal program and find out what it’s all about.
Over the course of the last quarter the Drupal Association engineering team has provided a variety of feature updates for the Drupal project in terms of testing infrastructure:
PHP8 Testing support – The Drupal Association provided PHP8 testing environments in DrupalCI, and so Drupal versions 9.1 and beyond are all fully PHP 8 compatible.Staying on the leading edge of compatibility gives Drupal the advantage of improved performance and security, and sets us up for success when it’s time for Drupal 10.
Code Standards test for Drupal Core – Drupal Core tests now provide code standards testing results, saving a laborious manual step when reviewing core contributions.
GitLabCI/Pipelines – The Drupal Association has also enabled GitLabCI/Pipelines for these new general projects. This is a precursor to moving to GitLabCI for all Drupal CI uses. With direct maintainer control of the CI configuration for these projects, we can see automated workflows to support a wider variety of projects – allowing for more innovation. However, we need to be cognizant of cost controls as we open up this capability.
The year is off to a fast-paced, productive start and as always it is humbling and gratifying to see the great work that the community accomplishes with the tools the Drupal Association provides.
As always, we’d like to say thanks to all the volunteers who work with us, and to the Drupal Association Supporters, who make it possible for us to work on these projects. In particular, we want to thank:
Do these numbers seem shocking to you? They certainly were for me. And the more unfortunate fact is that these numbers will only grow in the future. So, what should be done? We cannot stop people from getting a disability, that is in no one’s hand. However, we can ensure that that disability should not hold them back. We should endeavour for inclusion, wherein every person on this planet gets an equal opportunity, disability not being a criteria impeding on their life experiences.
To that accord, accessibility was designed, for inclusion, for equality and for making the differently abled feel that their voices and their feelings value. Accessibility has expanded as a concept since its inception and now, it is also being rigorously practised on the web.
The web or the internet is for everyone, you cannot say that it was designed with a particular demographic in mind because it simply wasn’t. From 5-year-olds watching YouTube videos that are making them prepared for school to 70-year-olds watching a YouTube tutorial on how to update their WhatsApp status, the internet is for everyone and web accessibility ensures that it can be accessed by everyone without difficulty.
This brings us to the meaning of web accessibility, which is to design something on the web that includes the needs of the differently abled. People with auditory, cognitive, visual and speech disabilities amongst others should be able to perceive, understand, navigate and interact with the web with ease. You should remember that accessibility is not just limited to people with disabilities, it also transcends to other aspects of life that may affect one’s ability to perceive what is right in front of them. Old-age, bright sunlight, the size of the device being used and the person’s mental and physical state at one point, all are included when we talk about accessible design on the web. Therefore, when businesses and organisations are able to build such experiences that cater to all of what I just mentioned, only then would they be truly accessible.
Here is a video to help you understand accessibility a little better.
“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”
With Tim’s words at the back of our minds, let’s find out what the fuss about accessibility is for. Here are three reasons that sum up the crux of accessibility and why it ought to be practiced down to the very of the web business.
Do you want to build a wider consumer base?
The paramount reason for practising accessibility lies in the numbers we talked about in the introduction. The close to one billion differently-abled people in the world would be able to access your web project with ease. They won’t feel frustrated or undervalued by your business model, if it is accessible. And can you guess what that means? Yes, you’ll be able to target a market that your competitors might have overlooked. And that is enough to get you the revenue you endeavour for.
Do you want to be on the good side of the law?
You know the United Nations? I’m sure you do. And when the UN says something is important and needs to be followed, you follow it. The United Nations Convention on the Rights of Persons with Disabilities clearly states that access to information and communications technologies is a basic human right. And when you make websites that are inaccessible to persons with disabilities, you are going against the UN and you won’t want that.
Even in the US, the Americans with Disabilities Act also establishes grounds for web accessibility and adherence to those guidelines is important to stay on the good side of the law, don’t you agree?
Do you want your brand image to be positive?
Then, there is the concern about brand image. If I had to describe accessibility’s essence, the only thing that would do it justice would be social inclusion. Including every section of the society and every scenario that may hamper their web experience, and building a web project that takes into account all of that would most definitely get positive feedback from the audience using it. And that is how you build a positive brand image.
Now, tell me are you not on the side of accessibility? Are you not craving to make the entirety of your website truly accessible to the users, whoever they may be, whatever their physical or mental condition be, and wherever they may be?
If that is the case, continue reading because I am going to be talking about accessibility tools that are found in Drupal, a leading CMS, so that you can use those tools and modules to make your site the epitome of accessibility.
Let’s Start by Understanding Drupal and Accessibility as One
Drupal has certain checklists that are used to evaluate the competence of a particular aspect of your project, these are called Drupal Core Gates. There are six in total, ranging from Content to Frontend and testing. And you would be glad to know that accessibility is one of these six parameters, this alone is explanatory enough to let you know how much Drupal prioritises this part of web designing.
Drupal’s Accessibility statement states that,
“As an inclusive community, we are committed to making sure that Drupal is an accessible tool for building websites that can also be accessed by people with disabilities.”
Drupal’s HTML structures also conform to WCAG 2.0 standards;
Drupal also focuses on adequate contrast between text colour and the background;
Drupal stresses on keyboard usability, thus testing a project by only using the keyboard is an important part of Drupal’s accessibility process;
Finally, Drupal emphasises on form fields being labeled to the proper standards.
All of these are proof of Drupal’s compliance with accessibility, meaning that Drupal is incomplete without it. With the additional WAI-ARIA support, Drupal is becoming all the more proficient in building projects that are accessible and rich internet applications.
With that said, let us look at the accessibility-centric features found in Drupal.
The Logic Semantic
The addition of WAI-ARIA landmarks, live regions, roles and properties has equipped Drupal to provide more semantic HTML5 elements that can be leveraged by assistive technology.
Let’s try to understand this, when an assistive device scans a web page for information, it extracts the data about the Document Object Model (DOM), or the HTML structure of the page. No further information is read by the screen reader.
Often these assistive devices only allow a user to select to read the headings on the page or only the links. It prioritizes according to the hierarchy in which the headings and links are presented making browsing easier for users of assistive devices. So, HTML and WAI-ARIA help in achieving screen-friendliness and making the UIs more interactive.
Aural users play a major role where accessible design is concerned. To that accord, Drupal.announce() has been made a part of Drupal core so that timely messages can be delivered to these users relying on a screen reader with different tones as well; you can be assertive or polite, it is up to you. This is the Aural Alerts feature.
The Tabbing Manager
Users that are visually impaired and the ones who cannot operate a mouse can opt for the Tabbing Manager. This is a feature that would essentially become a guide for these users, so that they are able to access all the salient features and that too in a logical order.
The CSS Options
Your content can be displayed in multifarious ways; it is up to you to decide how you want it. With Drupal’s CSS classes, you can control the way your content is hidden or not. Would certain screen readers can view it or all of them, would hidden, visually hidden or focusable or entirely invisible, you would get to decide every single nuance.
This is due to the centralised alternative to CSS display:none; and the standardisation of the HTML5 Boilerplate naming convention.
The Accessible Forms
It is important to provide the necessary feedback to users about the results of their form submission. Both the times when successful and when not. This incorporates an in-line feedback that is typically provided after form submission.
Notifications have to be concise and clear. The error message, in particular, should be easy to understand and provide simple instructions on how the situation can be resolved. And in case of successful submission, a message to confirm would do.
Drupal forms have turned out to be impressively more open to the expansion of available inline form errors. It is now easier for everyone to identify what errors they might have made when filling in a web form.
Fieldset labels are utilized as systems for gathering related segments of forms. Effectively implemented
The best open source distribution for Drupal just got better! The latest version of Rain University and Rain CMS now ship with Layout Builder pre-configured to make page building faster and easier. So how does it work? Check out below!
Now, when you navigate to any page with layout builder enabled you can edit the layout by clicking on the “Layout tab” under Tasks. Alternatively, you can click on the same tab while editing a page.
Rain CMS homepage
With layout builder you have an instant preview of any blocks added to the page. That being said, it’s usually easier to move blocks around with preview turned off. Drupal provides a checkbox that makes it simple to toggle preview on or off.
Rearranging blocks in Rain CMS
To add a block to the page click the “Add block” link in any section. Rain CMS ships with 15 block types out of the box that you can easily drop onto the page. Each component has a preview wireframe and label to help the author understand the look and function of each component.
Adding blocks in Rain CMS
One of the big benefits of Layout Builder is now you have more control over the layout of a page. Editors can easily add new sections with various layouts where blocks can be placed. Layouts can be customized per project.
Adding sections in Rain CMS
Rain University CMS
The Mediacurrent team has also updated our RainU CMS to ship with Layout Builder. Same great experience, but tailored specifically for universities.
We are also happy to demo Rain University or Rain CMS for organizations interested in partnering with Mediacurrent for your next redesign project. To schedule a free demo, please visit our contact page or chat with us right now (see bottom right corner of the page).
When someone comes to your website with an information need, they have two options: they can either use the site’s navigation to get where they need to go, or they can use the search function. We’re going to focus on the latter for this article.
Many of us do dozens or even hundreds of searches per day without even thinking about it: searching for an email, searching for that song on Spotify, figuring out what to make for dinner, looking up a contact on your phone, finding a word on this page.
We just expect search to work—but that’s easier said than done.
One of the tenets of design is to make things simple. When building a search interface, the goal is to make the interface as simple as possible, while ensuring that users can actually find what they’re looking for.
Before we get into specific design tips, let’s take a few seconds to think about how different users might interact with site search.
Information-seeking needs and behaviours
The type of information need a user has and how that user intends to retrieve said information will affect how they interact with a website’s search engine.
There are four main types of information need:
Exhaustive research: “I need to know everything about this topic”
Exploratory seeking: “I need to find a few good things”
Known-item seeking: “I’m looking for this specific thing”
Refinding: “I need this specific thing again”
When it comes to information-seeking behaviours, we can split searchers into four categories:
Retrievers know both what they need to find and how to find it. If they’re looking for a specific document on a site, they’ll simply type the document’s title into the search bar and expect it to be the top result.
Adventurers have a more general idea of their information need and waiting for something to catch their attention
Wanderers are unable to precisely define their information need
Explorers know exactly what piece of information they need, but they don’t know where or how to look for it
Every search interface will be used by each of these searchers, so keep them top-of-mind as you design.
📅 Free webinar: Designing a user-centric search experience (March 31, 2021). Sign up now!
Now, here are some key steps that’ll help you build out a solid search experience for your site.
We won’t get into the nitty-gritty details here, as you most likely already know who your personas are (and if not, we’d recommend taking the time to think about this before proceeding).
Personas—who your users are, how they think, what their habits look like—are the first step in most UX processes, and site search design is no different. Well thought out audience research will guide almost every decision you make throughout your search project.
2.Map out your users’ search journeys
Conduct user journey mapping exercises to gain insights on how a typical user would interact with the search.
Consider your personas and the types of searchers listed above. Who is using your search interface in each of these ways, and how should search fit into the larger user experience?
Be sure to consider these key variables that influence each search operation:
The user’s level of familiarity and comfort with search interfaces
The type of searcher (wanderer, explorer, adventurer, retriever) and their information need
The type of information being searched (content/page type)
The amount of information that needs to be retrieved
Another thing to keep in mind is the fact that searching isn’t always a straightforward, one-time process. On the contrary, browsing and searching often go hand in hand when a user is trying to fulfill an information need. The Wikipedia page about Cognitive models of information retrieval provides a succinct overview of these types of behaviours, if you’re interested in learning more.
3. Conduct user testing with real-life scenarios
Pick a few real use cases for the search interface and use them throughout the design, development, and QA process. When you conduct user testing, provide your subjects with a scenario-based goal and observe how they go about reaching it.
For example, if you’re testing the search functionality of a university website, you could ask your user something like “You’re getting ready to apply to the MA program in Film Studies. What documents do you need to include in your application?” or “You’re thinking about applying to this school as a non-resident. What fees can you expect to pay?”.
A few tips for carrying out user testing for search:
Work in pairs: one test subject with one member of the research team. One-on-one testing will provide the most valuable information.
During the test scenario, ask the subject to narrate their thought process out loud and take notes accordingly
Be ready to ask the test subject for any clarifications you might need as soon as the scenario is complete, so that it’s still fresh in their mind
4. Scope the search functionality
Start to plan out how the search interface would fit into the overall experience. Are there search pages embedded within specific sections of the website? Or a single search interface that the user is always directed to? Sometimes users want to focus on finding one thing (e.g. a directory of doctors or experts) and sometimes it’s more useful to allow them to expand their search to the entire website.
People have been searching for information online for quite some time now, which means users have all sorts of assumptions and expectations about search interfaces. Here are a few common ones that are useful to have in mind:
“I just need to type in some keywords and the search engine will do the rest”
“Using this search box will search the entire site”
“If I type in ‘syllabus’, the results will also find pages titled ‘course list’”
“I don’t have time to learn which of these search forms to use”
5. Incorporate incentives to search
The easiest way to invite users to search is to put a big search box on the homepage. Sometimes providing “suggested search” terms helps users get started, or prompting them what to type using a search suggestion. But you can also invite users to search by embedding a search form into other areas of the site, maybe pre-filtered based on the topic they’re exploring.
One thing to keep in mind is that users don’t typically have the motivation to actively figure out your search system. Give them a simple box, and support other information needs by being ready to offer users more options when they’re ready to consider them.
6. Design the results
The first thing to figure out is whether you want to divide or group the results by the form (e.g. the content type or media type). And then what will each result look like? How can you make the results engaging so the user has a better idea of what to click?
If you’re showing ten results on the page, you’re making the user do the final filtering manually, so make their life easier with richer results. And figure out what filter they will use most often and focus on this information (for example, events can prominently display the date and destinations can be displayed on a map).
A couple more tips:
Identify the taxonomy-type filters and make sure the content has this data. Remember that in Drupal, you can combine multiple vocabularies into a single filter.
Faceted search makes your filters more useful, because they will adjust based on all the other search criteria. This prevents the user from finding a dead-end in their search.
7. Add extra features
If you’re using Drupal and Elasticsearch or Apache Solr, it’s fairly simple to add more functionality to your search experience.
Here are just a few extensions that can make your site search more powerful:
Search term correction (spell check)
8. Tweak the boosting
Drupal’s Search API module allows you to easily adjust how each field is weighted when building the search results, which is referred to as “boosting”.
A good CMS can be recognised by how it deals with the URL addresses of individual subpages. Convenient linking attracts users from search engines and has a significant impact on SEO. In this article, I’ll introduce you to the Pathauto Drupal module, which is used to automate the creation of page aliases.
With this module, you can easily configure efficient, maintenance-free aliases for your content, including taxonomy terms and user pages.
The first version of Pathauto was released in February 2006 as an add-on to Drupal 4. Stable 1.0 version was released for Drupal 5 in 2007. The current code of this module from the 8.x-1.x branch is the result of a long evolution involving many members of the Drupal.org community.
The figures from the official statistics speak for themselves – the Pathauto module is used by over 640 thousand pages. And 32% of these are built on Drupal 8 and 9. We’re dealing here with one of the “essentials”, installed immediately at the stage of creating new projects.
The module is currently being maintained by four developers:
Since the beginnings of the Pathauto module, over 100 people have been involved in its development, creating a total of almost 1,600 commits. The tremendous contribution of the community is further evidenced by over 3,000 reported tasks and bugs on Drupal.org. Unfortunately, many of these remain unresolved.
Purpose of the module
With bare Drupal, you can create URL aliases for individual subpages, but you have to do it manually. If you don’t fill in the field with the alias, the new content will have standard, inconvenient addresses like /node/123 or /taxonomy/term/456.
The Pathauto module automates the addition of aliases by generating them according to the template with tokens specified by you. For example, static pages may have a title derivative address (/foo-bar), and taxonomy terms may contain a vocabulary name (/vocabulary-name/foo-bar).
You can download the module from Drupal.org or join the project by running the following command:
composer require drupal/pathauto
After launching Pathauto, go to its settings by selecting Configuration → Search and Metadata → URL Aliases → Patterns.
Pathauto offers a broad range of settings for the methods of generating aliases. It also allows you to carry out mass operations on already existing content. I’ll briefly describe below the most important options available.
URL address templates
The basic functionality of the Pathauto module is creating URL address templates, i.e. strings of characters containing tokens. Individual aliases are generated based on them when content is being saved.
I’ll explain it using the example of a blog. If you want your posts to be available under the address http://example.com/2021/foo-bar.html%20 containing the year of publication and the title, go to the panel Configuration → Search and Metadata → URL Aliases → Patterns and add a new template for the appropriate content type:
Try to create a new blog post now. It should get the address /2021/foo-bar.html. Note that you can still overwrite its URL alias, however by default it is generated automatically:
Page titles usually contain spaces and special characters. Pathauto module automatically converts them to the ASCII format separated by dashes. Then, a title like “How to Make Crème Brûlée?” will be replaced with a simpler version – “how-to-make-creme-brulee”. The settings for this conversion can be found in the “Settings” tab.
I suggest that you leave most of these options at the default position, but pay special attention to the “Strings to Remove” field. It contains strings of characters that will be removed from the address, including numerous English prepositions and articles. If you create a blog post titled “A Guide To Drupal”, you’ll end up with an address like /2021/guide-drupal.html, which is not always the desired result.
The other settings allow for very detailed customisation of transliteration in aliases, which is useful for multi-language support. Here you can, for example, decide on how to handle punctuation.
Mass generation of URL addresses
By default, Pathauto only generates aliases when the content is being saved. This means that if you change the URL template, the modification will not be reflected immediately in the aliases on the entire page. Also, after adding a new template, all its content will not get a new URL address immediately.
When creating large websites, it is often necessary to quickly regenerate aliases for the existing content. This is done with the “Bulk Generate” function, which enables mass operations on URL addresses.
Be very careful not to accidentally overwrite the existing aliases with newer versions. Here I would recommend installing the Redirect module, which saves the redirects between the old and new subpage addresses.
The Pathauto module also has an advanced panel for removing aliases. Be very careful when using it. Any changes introduced here are irreversible. You’ll probably need the “Only delete automatically generated aliases” option to prevent deleting manually overwritten aliases.
Hooks and integrations
Pathauto from the 8.x-1.x branch allows you to handle any kind of entities with plugins like @AliasType, and also provides some simple hooks:
hook_pathauto_is_alias_reserved() – blocks the creation of an alias if it is reserved by another module. In such a case, a number will be added to the alias (e.g. /foo-bar1).
hook_pathauto_punctuation_chars_alter() – it is used to add new punctuation settings.
hook_pathauto_pattern_alter() – allows you to modify the URL address template.
hook_pathauto_alias_alter() – allows you to change the alias after generating it.
When creating your own Drupal modules, you should think about adding an optional configuration for Pathauto to them. This is quite a common practice, for example in the Group module. As a result, the user receives default, ready-made alias templates.
Dealing with URL addresses in Drupal
Pathauto is an extremely powerful module that is used in most of our Drupal development projects. It keeps URL addresses consistent and frees editors from having to manually form aliases. Its usefulness is confirmed by hundreds of thousands of installations reported in the official statistics. I definitely recommend getting better acquainted with its abilities.
Drupal doesn’t support the ability to replace existing files. You can create and delete files, but you can’t replace a file without using a module. If you try to upload a file with the same name Drupal will append “_0”, “_1”, etc… to the filename and increment it.
What is the main difference between Media Entity File Replace and File Replace?
Both modules will replace “files” whilst retaining the original file’s filename by performing an “overwrite” function in the backend. In Drupal, an uploaded “file” can be a “media entity” or a “file entity”.
The Mediacurrent team is proud to support this community event as a platinum sponsor. We’ll be presenting several sessions at this year’s online conference.
Whether you’re a site builder scaling up with multisite, a marketing leader in search of current guidance on open source security, or a Drupal community member of any kind looking for inspiring real-world case studies, we’ve got you covered.
Here’s what we have in store for sessions and case studies in Drupal innovation:
Unlock The Power of Multisite
Join Jay Callicott, Mediacurrent’s VP of Technical Operations, for a comprehensive approach to manage your Drupal sites at scale.
Interested in evaluating multisite options for your organization? Jay will cover several ways to scale your Drupal platform from one site to many dozens or even hundreds.
Register here to join the session and learn best practices for governing multiple sites from one codebase, how to configure a multisite installation, and considerations for your hosting solution.
Open Source Security for CMOs
As open source software continues to become widely adopted, adhering to security standards is becoming more challenging. So what’s a CMO to do?
Inspired by our ebook, The CMO’s Guide to Open Source Security, this session will help you navigate the terminology, expectations, and tools to ensure security is a priority for your web properties.
Imagine a world where everyone has a decent place to live. That’s the vision fueling Habitat for Humanity to create ambitious digital experiences with Drupal.
This session will present a case study covering how Drupal is being used to bring mission-driven innovation to reality for this international nonprofit. Both Drupal site builders and non-technical roles are encouraged to attend.
Stay tuned for scheduling information!
Drupal for Higher Education
The year 2020 called for higher ed leaders to accelerate digital marketing strategies. For many, Drupal was a key part of the equation. This rang true among a spectrum of Mediacurrent’s higher education partners, including an Ivy League university that chose a decoupled architecture for its breakthrough knowledge platform.
Dan Polant, Director of Development at Mediacurrent, will share that story in a co-presented session at the Higher Education Summit. The session will explore the University’s driving mission to build toward a brighter financial future on a Drupal and React-based platform.