Drupal Planet

Ben's SEO Blog: Drupal SEO Guide

5 days ago
Drupal SEO Guide

 This guide is an extension of the first ever published book with the step-by-step, technical details you need to search engine optimize a Drupal website. Originally written by Ben Finklea (Volacci's Fearless Leader) in 2017, it is the first step to digital marketing excellence that will reward you with increased ranking, traffic, customers, and sales.

While these instructions were written for marketers, developers can also benefit. The ability to provide a more easily SEO'd website to a client will always be in demand. Should you wish to partner with Volacci on SEO services for new websites, please feel free to reach out to us.

Bookmark this page! We will keep this section updated with the latest Drupal release instructions, but please be patient -- research and writing takes time.

What this guide is.

If you were sitting at the desk next to us right now and needed help with a Drupal SEO technical problem, we’d just tell you how to solve it, walking you through the necessary steps. That’s what this guide is.

What this guide isn’t.

We won't go into detailed, basic explanations on what SEO is and why it's important. There are many great resources online with full explanations of how SEO works, what Google is looking for, and how to win the online marketing game. We’ll link to some good ones so you can dig deeper when you need to. We’re especially fond of Moz.com, and always send people to their Beginner’s Guide to SEO if they’re just starting out.

We explain how we do the technical SEO on a Drupal website. It’s not the only way, but we’ve found it’s the way that works best for us. If you get through this guide (or get too busy to complete it), and your site is still not ranking, then seek professional help

How to read this guide.

It’s best to install the SEO Checklist module, and check the items off as you complete them. This guide details each section of that Checklist.

Throughout this guide, you’ll find various text styles to help make concepts clearer or to draw your attention to important aspects of a task. Here are some examples:

  • Italic. Warnings or critical terms.
  • Bold. New words or to draw attention.
  • Code. URLs or code snippets
  • "Quotes". Interface elements you’re interacting with.
     
Notes, Tips, Warnings

Extra information that helps you better understand a concept, avoid a misstep, or give additional functionality.


Sometimes, it can be helpful to know how hard a task is going to be, so we’ve included them to make things clear. Here’s what they mean:

  • Easy: Straightforward and quick.
  • Normal: A bit more involved, maybe 2 or 3 separate steps but no heavy lifting.
  • Hard: It’s going to take some thought and time to do this. Still, most marketers should be able to knock it out with some effort.
  • Expert: This task is time-consuming, technical, or difficult. You may need to get some help from a Drupal developer to get it done.
Tracy Cooper Tue, 04/06/2021 - 16:43

OpenSense Labs: The Drupal Factor in Web Accessibility

5 days 5 hours ago
The Drupal Factor in Web Accessibility Gurpreet Kaur Tue, 04/06/2021 - 23:09

Close to a billion people are said to be living with a disability across the globe; 
Every fourth adult in America is battling a major disability everyday of their life; 
As many as 217 million people are suffering from visual impairment;

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. 

Why Do You Need to Prioritise Accessibility? 

After looking at the meaning of accessibility, it is important to understand its importance. Until we know the true value of something, we don’t become inclined to accept it. And accepting accessibility and implementing it has to be a priority today

Tim Berners-Lee, Creator of World Wide Web and Director of W3C said,

"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.”

And there is more; 

  • Drupal stringently adheres to the World Wide Web Consortium’s WCAG 2.0 and ATAG 2.0 guidelines in its core operations;
  • 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.

The Readouts 

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.

The Fieldsets 

Fieldset labels are utilized as systems for gathering related segments of forms. Effectively implemented label gives a visual diagram around the shape field gathering. This can, to a great degree, be valuable for individuals with cognitive disabilities as it viably breaks the form into subsections, making it easier to understand.

Drupal presently uses fieldsets for radios and checkboxes in the Form API. This helps towards additionally upgrading forms in Drupal. This feature is also being used in the advanced search option. 

The Alternative Text 

People with good eyesight can see the images, but what about the visually impaired? They won’t be able to see the images. And images are important in context to what you want to portray in your content. So, what is the solution?

It is an alternative text, this text describes everything going on in the picture, so that the people without sight are able to understand what the picture is about. 

Drupal has alternative text as default to make the content accessible to everyone and content creators understand its importance. However, the default can be overridden through CKEditor or Image Fields, if that is what you might prefer. 

The Bartik 

If you think about it, a link is like any other piece of content on a webpage, yet it is different because it has the power to take you to a different page for more information. This power should be highlighted properly. And Bartik is here to help in that. A Bartik underlines a link, which basically highlights it and makes it easily identifiable, aiding to enhance accessibility further. 

The jQuery UI 

Drupal’s autocomplete feature is quite useful and jQuery UI is helping in elevating its usefulness. Being implemented in Views UI and in other places, it is improving Drupal’s accessibility standards. With the involvement of jQuery UI community, the benefits are being experienced by both the projects in leaps.

Drupal Accessibility Also Transcends to Developers: D7AX

When we hear accessibility, we always go to the users. Accessibility has to be about them, right? We must ensure that everything on the site is totally accessible to every user, regardless of their physical condition. 

This notion is true, yet it is only half true. Yes, the majority of the accessibility guidelines focus on the users, however, the developers, the people who actually build a project from the ground up also need to prioritise in terms of accessibility. So, the development process has to be accessible for them to build something great that they are fully capable of doing.

And Drupal provides this as well. Drupal has focused on accessibility for developers and that is what makes me as a Drupalists proud of this platform. Developers can depend on Drupal for support when they are creating accessible sites and projects. 

The D7AX is shining glory of Drupal in this accord. It makes it extremely convenient for developers to find contributed modules and themes that support the development of accessible websites. 

So, what is D7AX? 

It is a kind of platform that lets other developers know that a module has been designed after following all the resources for developing accessible modules. When you see a hashtag saying D7AX on a module page, know that it is accessibility friendly. 

Whenever you use a D7AX module, you are contributing in making that module a success. Using it would mean any issues that were overseen before might be caught by you and resolved, making you a D7AX developer as well and a contributor in Drupal accessibility, 

What about themes? 

D7AX is not just limited to modules, it also works to resolve the accessibility challenges found in the theme layers. It works in similar fashion to that of modules and the hashtag lets the users know that a theme is compliant to the accessibility guidelines. The Accessibility handbook will help you further in this regard. 

Is there an accessibility group?

Yes, there is and it is the Drupal Accessibility Group. It would answer all your questions about Drupal accessibility and make accessibility come alive on your fingertips. With regular sessions and talks, you’ll get to know all the hints, tips and tricks about it. 

Your feedback is always going to be valued at Drupal, the accessibility group is no different. Even if you have concerns about Drupal lacking in an aspect of accessibility, you should raise it. Who knows maybe you end up making Drupal even better. 

This is the kind of indulgence by developers as part of one community that makes Drupal an ideal place for developers to build something that is universally accessible because they have access to the ideas and work of other developers and that gives Drupal an unparalleled edge. 

Modules Making Drupal Sites Universally Accessible

Knowing that Drupal caters to accessibility for the administrators and developers as well as the visitors does give a sense of relief that we are going on the right track with Drupal. However, is that enough? I don’t think so. 

Until you know how to effectively implement the aforementioned accessibility features into your project, you can’t sit back and relax. To help you in executing accessibility to the T, here is a list of the modules that will enable you to deploy a universally accessible project. 

#1 The CKEditor Family 

You cannot talk about Drupal accessibility modules without talking about the CKEditor. It is a WYSIWYG module that provides umpteen features like structured content and clean markup and convenient drag and drop features based on its UI along with pretty secure safety guidelines for your content creators.

The CKEditor in itself is pretty powerful when it comes to accessibility, however, when you bring five of its variants into the mix, it has the potential of making Drupal even more accessible. Let’s have a look at them now.

CKEditor Accessibility Auditor 

The HTML_CodeSniffer Accessibility Auditor comes in the package of CKEditor Accessibility Auditor with a button for the same that audits the source code of your current content. 

If you have a specific error; 
If you want a success criteria and suggestions of techniques; 
If you want to know what triggered the error; 

Everything would be found by these modules and the results will be in front of you almost as soon as you run the auditor.

CKEditor Accessibility Checker 

The CKEditor Accessibility Checker provides a plugin with a creativeness for accessibility inspection of your WYSIWYG body created in the CKEditor itself. Of course, the inspection would lead on to immediate solutions of any problems found. You should know that this innovation plugin is the Accessibility Checker, hence the name of the module.

CKEditor Balloon Panel 

This module is used in relation to the previous one to create floating panels that have accessibility tips. These floating panels are a courtesy of Balloon Panel plugin that make it possible for you to present as content at whichever specific position you want to, 

CKEditor Abbreviation 

The CKEditor Abbreviation’s purpose is quite simple. If you want to add a button to the CKEditor to help you insert and edit abbreviations, it will do that for you. The addition of a link to edit the abbreviation is an added bonus.

USWDS CKEditor Integration

Like the name says, the USWDS CKEditor Integration module integrates the US Web Design System to the CKEditor, which has become a requirement for government websites. You can use the USWDS classes and components and inject them into the CKEditor, all without opening the source even once.

#2 Automatic Alternate Text 

Did you know that there is an API that can actually process images through its state-of-the-art algorithms and return with an output that is quite on point? It can sense the content of the image, its maturity levels and even the prominent colours in it. 

The Microsoft Azure Cognitive Services API is able to do this with ease. Drupal’s Automatic Alternative Text module utilises the competence of this API and provides alt text to images your users did not. 

However, you must be aware of the fact that the way we perceive images and the technology would perceive it may not be similar, so the produced alt text can be different to what you may have expected. 

#3 A11Y:Form Helpers 

Remember the accessible forms I mentioned as a Drupal feature, the A11Y: Form Helpers helps in achieving that. It aims to fix the accessibility issues found in Drupal forms. 

This module’s features are quite impressive. 

  • You do not require any HTML validation; 
  • You can include readable inline error messages for screen readers; 
  • You can even put in pre-filled attributes to certain form elements, which is always a winner.
#4 Block ARIA Landmarks Role

People usually prefer when you come straight to the point and skip all the small talk. And ARIA landmarks are just the means for that; it allows users to skip the unnecessary and switch to the main content. 

With the Block ARIA Landmarks Role, you can add extra elements to the block configuration forms and users can allocate an ARIA landmark role or label to a specific block. Having been created with inspiration from the Block Class, this module does cater to accessibility.

#5 Editoria11y

Editoria11y is a module that caters to the accessibility needs of the content creators and editors. Being a user-friendly checker, it focuses on the accessibility concerns of content authors and rectifies them. 

  • It ensures that speckcheck is always on and corrects the content mistakes as and when they happen.
  • It ensures that errors never happen in relation to Views, Layout Builder, Media and similar modules. This is because it runs in context with them and its checkers are always running.
  • Lastly, it ensures that content issues get fixed by prioritising them. Its exclusive focus on them ensures page editors don’t miss anything that is easily fixable by them.
#6 Fluidproject UI Options 

A web page has a lot of different elements that might need modifications to make them aligned with the accessibility standards set by Drupal and W3C. The Fluidproject UI Options tends to make these modifications easy for you. 

Be it; 

  • the page’s font size;
  • the page’s font style; 
  • the page’s height; 
  • the page’s contrast ratios; 
  • the page’s link style; 

everything can be sorted and the changes can be retained using cookies. However, it does come with certain limitations, using CSS gradients for contrast settings is one of them. 

#7 High Contrast 

You will have a theme that you are currently using, then there will be a theme that would be a high contrast version of the same. Reading this along with the name of the module, you must be able to guess what this module is all about. 

With High Contrast, you will be able to switch between your theme and a high contrast version of the same. All you would need to do is press tab on the keyboard after installing the module and you’ll get the high contrast pop-up link on your screen and the work is done.

#8 Siteimprove

Aiming for high quality content along with higher traffic and a higher level of digital performance is not unreasonable. And doing all of this by adhering to the regulatory compliance is what Siteimprove is known for. 

Being a comprehensive cloud-based Digital Presence Optimisation software, it offers a smooth integration through its Drupal module, wherein  you can capitalise Siteimprove efficiency in content creation and editing process.

Be it testing the content; 
Be it fixing what was found; 
Be it optimising the perpetual work; 

You will have the analytics and content insights at your disposal to make this happen. Siteimprove’s plugins ability to lessen the gap between Drupal and the software’s Intelligence Platform is the sole reason for these amazing benefits. 

#9 Style Switcher 

Have you ever found yourself in a conundrum wherein creating themes and building sites seems like a mammoth task? If you have, you most likely would have been facing issues with the alternate stylesheets. 

The Style Switcher module makes all of this a breeze by focusing on the themer as well as the site builder. It provides an alternate stylesheet for both in the admin section. These styles are presented in a list of links in a block to your site visitors. 

And there is more, with the module making use of cookies, these styles are always remembered and when someone returns to a page, he is welcomed by the same style he chose in his previous visit. Pretty amazing, right?

#10 Text Resize 

Have you ever squinted your eyes to read a piece of text that is too small? Did you get frustrated by it? Now, imagine you have a weak eyesight and focusing is always an issue. Would you be able to read a small font size? I don’t think you will and now you know how the visually impaired feel.

The Text Resize module helps in making the visually impaired feel less frustrated. Using jQuery and jQuery Cookie, it creates a Drupal block that allows users to change the font size of the text, making your pages more accessible. You would be glad to know that it can also resize images. However, you have to remember to enable the Text Resize block of your theme, only then would the block appear. 

#11 Civic Accessibility Toolbar  

Civic Accessibility Toolbar has a pretty similar principle to the previous module. Unlike the Text Resize module, it not only aids changes in the font size of the text, but it also helps users in switching to a theme version that has a higher contrast. 

Now, much like Text Resize, this module also operates on the creation of blocks for the utilities being implemented for accessibility with the visually impaired in mind. 

Bartik, Garland, Zen Starterkit, Stark and Oliveiro are all the themes in which the Civic Accessibility Toolbar has been trialed and tested.

#12 HTML Purifier

Auditing your site with a thorough and secure whitelist as well as ensuring that your documents are compliant to the standards of W3C’s specification will keep you on the good side of accessibility. Drupal’s HTML Purifier module does just that through the HTML filter library of the standard stringent HTML Purifier

With this module you can say goodbye to all malicious code.

Custom fonts; 
Inline styles; 
Images and tables; 
Restricted tags; 

All of these are possible when you combine the HTML Purifier with your WYSIWYG editors. You will hit the standard compliant ball out of the park with a home run through this module. 

Now that we have discussed all the necessary modules that aid in making your Drupal site universally accessible, let’s listen to what one of our frontend developers at OpenSense Labs has to say about Drupal and its part in accessibility.

“Drupal Core on its own takes care of the accessibility in the site. Since many accessibility challenges are confined to Frontend (Theme) Layer, it is better to have good practices in place for frontend development to ensure accessibility compatible sites.” 

I personally feel that he is right. There are hundreds of modules in Drupal and you can use as many of them when building your site. With so many modules at work, your site is bound to be extremely functional and impressive. However, it still might not be accessible, if you don’t keep accessibility as an imperative parameter during the building process. 

I’ll explain this with a few modules for better understanding. 

If you look at all of these modules, they are not blatantly related to accessibility, but all of them are somehow adding to your site’s accessibility appeal. Now, if you developers are constantly building with accessibility at the back of their minds, they would use these modules without any hesitation. 

Therefore, like our frontend developer said, Drupal accessibility is all about good practices throughout the building process and throughout the life of the web project. 

Are You Certain Your Project is Accessible, Let’s Review!

Up until now we have discussed the accessibility features found in Drupal and the modules that support the implementation of those features. Do you think that is enough? Do you think the installing and running a bunch of modules makes all your accessibility work done and now you can sit back and relax? If you think so my friend, you are utterly wrong. 

By running modules, you cannot be certain that your site is truly accessible, that it checks all the accessibility boxes. You have to run a thorough review on all the parameters that can affect your site’s accessibility and after reviewing the results and rectifying them, you can sit back and chill as much as you want. 

So, let’s start the review.

Review through Automation 

You need to start your reviewing process with Drupal’s automated tools that are designed to assess your project’s accessibility levels and issues arising out of it and consequently resolving them. 

Some of these tools are; 

WAVE;
Tenon;
Accessibility Insights;
Google Lighthouse;
Siteimprove;
And Siteimprove Accessibility Checker.

With axe-core, you can automate some of them and sit back while they do their work.

Review the Keyboard

Keyboard navigation is of great significance when it comes to web accessibility, so you cannot afford to go wrong with it. Everything and every element on your screen must be accessible through a keyboard and with a tab order that makes sense.

When making your assessment, look for things like these; 

  • The tab should work forwards and backwards; 
  • The interactive elements should be highlighted from others; 
  • The document object model should be followed in the tabbing progression, making it natural; 
  • The skip option is available for content that is repeated; 
  • The user should be able to skip overlays, modals and autocomplete widgets; 
  • The hovering mouse content should be accessible through the keyboard as well. 

Pointers like these amongst others would make your project keyboard friendly. One more thing, you should remember to review this on mobile and tablets as well to avoid any responsive breakpoints.

Review the Colour and Contrast 

Next comes the colour and the contrast, which should be prioritised too. The foreground and the background need to be quite distinguished from each other. 4.5:1 is the ideal ratio of text to the background. Anything lesser than that would be in direct contradiction to the accessibility guidelines. 

You also need to remember that colour cannot be the only way to relay information. Think of your audience, who might be colour blind; would they be able to gather what you are trying to say?


The second demonstration in this image is what you should always go for. 

Review the Content 

You also need to review your content. By content, I don’t exactly mean the words you use, although the language should be easy to understand. 

Apart from that, there is also the changing content such as the list of search results, which keeps updating all the time. This is called the dynamic content and you must announce these changes through assistive technology; ARIA Live Regions help in this regard.

Headings are a part of the content as well. In this regard, you have to make sure that your headings are not only prominent enough, but also descriptive enough to ensure that something reading it understands its entire context. 

Then there are the icons, which cannot just be the icons because the users would not be able to know their functionality without a proper description. Give labels to all your icons, if you haven’t already. 

Review the Sound and Video 

This one is for the deaf community and people who have hard hearing problems. The elements on your site that are relaying information through sounds and videos should have accompanying textual transcripts and captions so that people who cannot hear what is being said and read it. This would automatically make your site more accessible. 

I used both captions and textual transcripts because this review also focuses on the users with visual impairments. This is because for a complex video, captions alone may not be enough. There may be a need to textually describe the scene to people who cannot see what is happening and captions would only provide context to some degree. 

Review the Animations and Autoplay 

There is a high chance that your project might have animations, audios and videos. Obviously, there would be a purpose for their presence on your site, but you have to consider the user as well and that means avoid autoplay. 

Videos that autoplay and don’t pause by themselves are a nuisance to me, frankly, if I want to watch, I’ll press play myself. So, you should also turn the autoplay option off and even if it is on, the animations, audios and videos should stop playing after a couple of seconds. 

You should also think about adding easy controls to play and pause these media items. 

Review the Screen Reader 

You are going to have users that would completely rely on a screen reader, so ensuring that there are no issues with that has to be on your review checklist. 

For this, 

  • You should assess that the same information is being relayed to users using assistive technology and the sighted users. 
  • You should check the flow of information, ensuring that it is logical much like the tabbing order in keyboard accessibility. 
  • You should see that all your links make sense; something like ‘click here’ won’t really help the screen reader user. 
  • Finally, you should ensure that all the images have alternative text describing them in a clear and concise way. 
Conclusion 

Web accessibility has become quite popular today. If you adhere to the W3C’s guidelines on accessibility, you could achieve wonders for your brand image and enhance your consumer base to a great deal. However, if you do not, your image would downgrade and so would your revenue. The aim of accessibility should be to create a web project that is accessible to someone without any disability, someone with a physical disability and someone with cognitive disabilities on an equal without a shadow of bias.

Accessibility features in Drupal are so comprehensive and whole that they would not let the latter outcome be even an option. I have tried covering all of Drupal’s accessibility modules and tools and I really hope that you will take a note of them and build a project that gets universal attention. Good luck!

blog banner blog image Web Accessibility Drupal Drupal Web Accessibility Drupal accessibility Blog Type Articles Is it a good read ? On

Morpht: Drupal 8 Configuration - Part 2: How the API works

5 days 9 hours ago
Background

We live in an age of Drupal complexity. In the early days of Drupal, many developers would have a single Drupal instance/environment (aka copy) that was their production site, where they would test out new modules and develop new functionality. Developing on the live website however sometimes met with disastrous consequences when things went wrong! Over time, technology on the web grew, and nowadays it's fairly standard to have a Drupal project running on multiple environments to allow site development to be run in parallel to a live website without causing disruptions. New functionality is developed first in isolated private copies of the website, put into a testing environment where it is approved by clients, and eventually merged into the live production site.

While multiple environments allow for site development without causing disruptions on the live production website, it introduces a new problem; how to ensure consistency between site copies so that they are all working with the correct code.

This series of articles will explore the Configuration API, how it enables functionality to be migrated between multiple environments (sites), and ways of using the Configuration API with contributed modules to effectively manage the configuration of a project. This series will consist of the following posts:

Part 1 gives the background of the Configuration API, as well as discusses some terminology used within this article, so it's worth a read before beginning this article.

Active configuration is in the database

In Drupal 8, configuration used at runtime is stored in the database. The values in the database are known as active configuration. In Drupal 7, configuration was known as settings, and stored in the {variable} table. In Drupal 8, configuration is stored in the {config} table. The active configuration is used at runtime by Drupal when preparing responses.

Configuration is backed up to files

The Configuration API enables the ability to export the active database configuration into a series of YML files. These files can also be imported into the database. This means that a developer can create a new Field API field on their local development environment, export the configuration for the new field to files, push those files to to the production environment, then import the configuration into the production environment's active configuration in the database.

The configuration values in the database are the live/active values, used by Drupal when responding to requests. The YMLfiles that represent configuration are not required, and are not used at run-time. In fact, in a new system the configuration files don't even exist until/unless someone exports the active configuration from the database. The configuration files are a means to be able to back up and/or migrate configuration between environments. Configuration files are never used in runtime on a site.

Configuration architecture

Let's look at the Configuration API on a more technical level, using a real-world example. The Restrict IP module allows users to set a list of rules that whitelist or blacklist users based on their IP address. Upon visiting the module settings page, users are presented with a checkbox that allows them to enable/disable the module functionality.

From a data standpoint, checkboxes are booleans; they represent either a true or false value. When exporting the configuration of a site with the Restrict IP module enabled, the relevant configuration key will be saved with a value of either true or false to a .yml file. Modules are required to define the schema for any configuration the module creates. Developers can look at the configuration schema declarations to understand what file(s) will be created, and what values are accepted.

Modules declare the schema for their configuration in the [MODULE ROOT]/config/schema directory. In the case of the Restrict IP module, the schema file is restrict_ip/config/schema/restrict_ip.schema.yml. This file contains the following declaration:

restrict_ip.settings:
  type: config_object
  label: 'Restrict IP settings'
  mapping:
    enable:
      type: boolean
      label: 'Enable module'

Schema declarations tell the system what the configuration looks like. In this case, the base configuration object is restrict_ip.settings, from the first line. When this configuration is exported to file, the file name will be restrict_ip.settings.yml. In that file will be a declaration of either:

enable: true

Or:

enable: false

When the file restrict_ip.settings.yml is imported into the active configuration in another environment's database, the value for the enable key will be imported as defined in the file.

On top of this, enabled modules are listed in core.extension.yml, which is the configuration that tracks which modules are enabled in a given environment. When the Restrict IP module is enabled in one environment, and configuration files exported from that environment are imported into a different Drupal environment, the Restrict IP module will be enabled due to its existence in core.extension.yml, and the setting enable will have a value of either true or false, depending on what the value was exported from the original environment.

Note that if you were to try to import the configuration without having the Restrict IP module in the codebase, an error will be thrown and the configuration import will fail with an error about the Restrict IP module not existing.

Summary

In this article, we looked at how the Drupal 8 Configuration API works on a technical level. We looked at how active configuration lives in the database, and can be exported to files which can then be imported back into the database, or migrated and imported to other Drupal environments. In part 3 of the series, Using the API, we will look at how to actually use the Configuration API, as well as some contributed modules that extend the functionality of the Configuration API, allowing for more effective management of Drupal 8 projects.

Morpht: Drupal 8 Configuration - Extending the API

5 days 9 hours ago
Background

We live in an age of Drupal complexity. In the early days of Drupal, many developers would have a single Drupal instance/environment (aka copy) that was their production site, where they would test out new modules and develop new functionality. Developing on the live website however sometimes met with disastrous consequences when things went wrong! Over time, technology on the web grew, and nowadays it's fairly standard to have a Drupal project running on multiple environments to allow site development to be run in parallel to a live website without causing disruptions. New functionality is developed first in isolated private copies of the website, put into a testing environment where it is approved by clients, and eventually merged into the live production site.

While multiple environments allow for site development without causing disruptions on the live production website, it introduces a new problem; how to ensure consistency between site copies so that they are all working with the correct code.

This series of articles will explore the Configuration API, how it enables functionality to be migrated between multiple environments (sites), and ways of using the Configuration API with contributed modules to effectively manage the configuration of a project. This series will consist of the following posts:

Part 1 gives the background of the Configuration API, as well as discusses some terminology used within this article, and Part 2 describes how the API works, and Part 3 explains how to use functionality provided by core, so they are worth a read before beginning this article. 

Read-only configuration

In some situations, site builders may want to prevent any configuration changes from being made on the production environment, preventing changes that may cause unexpected issues. For example, clients with admin access could log into the production server, and make what they think is an innocent configuration change, that results in unexpected and drastic consequences. Some site builders consider it to be a best practice to prevent configuration changes on the production server altogether, under the idea that only content should be editable on the production server, and configuration changes should only be made in development and/or staging environments before being tested and pushed to production.

The Config Readonly module, allows for configuration changes through the UI to be disabled on a given environment. It does this by disabling the submit buttons on configuration pages. The module also disables configuration changes using Drush and Drupal console.

A configuration form that has been disabled with the Configuration Readonly module

Note: some configuration forms may still be enabled when using this  module. Module developers must build their forms by extending ConfigFormBase for the Configuration Readonly module to do its magic. If the developer has built the form using other means, the form will not be disabled, and the configuration for that form can be changed through the admin UI.

To set up an environment as read-only, add the following line to settings.php, then enable the module:

$settings['config_readonly'] = TRUE;

After an environment is set as read-only, changes to configuration can only be made on other environments, then migrated and imported into the active configuration on the read-only environment.

Complete split (blacklist) configuration

Sometimes configuration needs to exist on some environments, but not exist in other environments. For example, development modules, like the Devel module, or UI modules like Views UI (Drupal core) and Menu UI (Drupal core) should not be enabled on production environments, as they add overhead to the server while being unnecessary since the production server should not be used for development.

A problem arises when configuration is exported from one environment, and imported into the production environment. All the configuration from the source environment is now the active configuration on the production environment. So any development modules that were enabled on the source environment are now enabled on the production environment. In the case of development modules like Devel, this may only add some overhead to the server, but imagine a module like the Shield module, which sets up environments to require a username and password before even accessing the site. If this module is accidentally enabled upon import on production, it will block the site from public access - a disaster!

The solution to this situation is to blacklist configuration. Blacklisted configuration is blacklisted (removed) from configuration upon export. This functionality is provided by the Configuration Split module. This module allows for black-listing configuration either by module, by individual configuration key(s), and/or by wildcard.

Note that more detailed directions for creating blacklists can be found on the documentation page. The following is meant to give an overview of how black lists work.

Blacklists are created as part of a configuration profile. Configuration profiles allow for 'splitting' (a divergence in) configuration between environments. Profiles may be created for environment types such development, staging and production allowing for configuration specific to those types of environments. Or profiles could be set up for public non-production environments, that would have the Shield module enabled and configured. While a development profile may apply to all development environments, not all development environments are on publicly accessible URLs, and therefore may not need the Shield module enabled.

When setting up a configuration profile, note that the folder name must be the same as the machine_name of the profile.

Configuration split profile settings

Note that you must manually create the folder specified above, and that folder can and should be tracked using Git, so it can be use on any environment that enables the profile.

Configuration can then be set up to be blacklisted either by module, by configuration key, or by wildcard:

Complete split (blacklist) can be set by module, configuration key, or by wildcard

Finally, environments need to be set up to use a given profile. This is handled by adding the following line to settings.php on the environment:

$config['config_split.config_split.PROFILEMACHINENAME']['status'] = TRUE;

Where PROFILEMACHINENAME is the machine_name from the profile you created.

Although blacklisted configuration does not become part of the exported archive, it is not ignored altogether. When an environment has the profile enabled, upon export, blacklisted configuration is extracted, then written to the folder specified in the profile. The remaining configuration is written to the default configuration directory. When importing configuration, environments with the profile enabled will first retrieve the configuration from the default configuration directory, then apply any configuration from the folder specified in the profile. Environments not set up to use the profile ignore the configuration in the blacklisted directory altogether on both import and export.

This means that a developer can enable the Devel module on their local environment, blacklist it, then export their configuration. The blacklisted configuration never becomes part of the default configuration, and therefore the module will not accidentally be installed on environments with the configuration profile enabled.

Conditional split (grey list) configuration

Grey lists, also provided by the Configuration Split module, allow for configuration to differ by environment. With a blacklist (previous section), the configuration only exists in the active database configuration for environments that are set up to use the configuration profile containing the blacklisted configuration. With a grey list, the configuration exists in the active configuration in all environments, but the configuration profiles can be set up to allow environments to use differing values for the configuration.

Imagine an integration with a remote API requiring a username, password, and endpoint URL. The production server needs integrate with the remote API's production instance, while other environments will integrate with the remote API's sandbox instance. As such, the values to be used will differ by environment:

Production Environment:

remoteapi.username: ProductionUsername
remoteapi.password: ProductionPassword
remoteapi.endpoint: https://example.com/api

Other Environments:

remoteapi.username: SandboxUsername
remoteapi.password: SandboxPassword
remoteapi.endpoint: https://sandbox.example.com/api

A grey list allows for the setup of these values by configuration profile.

You may be remembering that Part 3 of this series of articles discussed overriding configuration in settings.php, and thinking that a grey list sounds like the same thing. After all, the default values for the sandbox instance of the API could be set up as the configuration values, and the production values could be overridden in settings.php on the production environment, with the same end-result.

The difference is that with a grey list, the remote API values are saved to the configuration profile folder, which is tracked by Git, and therefore can be tracked and migrated between environments. When grey listed configuration is exported, the grey listed configuration is written to the configuration profile folder, in the same manner as blacklisted configuration. When configuration is imported, the default values are retrieved, and the grey list values are used to override the default values, after which the configuration is imported into active configuration.

With the configuration override method using settings.php, site builders need to store the various configuration values somewhere outside the project, communicating environment-specific configuration values to each other through some means, to be manually entered on the relevant environment(s). With a grey list, the configuration values are managed with Git, meaning site builders do not need to record them outside the project, nor communicate them to each other through some other means. Site builders simply need to enable the relevant configuration profile in settings.php, and the environment-specific values can then be imported into active configuration from the configuration profile directory. This means that the sandbox API values can be set up as the values used by default on all environments, and a production configuration profile can be enabled on the production environment using the values to connect to the production instance of the remote API.

Conditional split items can be selected either from a list, or by manually entering them into the configuration profile:

Conditional split (grey list) settings can be selected or manually entered

Finally, note that grey lists can actually be used in conjunction with configuration overrides in settings.php. Grey lists are applied during import and export of configuration from the database. Values in settings.php are used at runtime, overriding any active configuration. So a developer could choose to set up their local instance of the system to connect to an entirely different instance of the remote API altogether by overriding the values in settings.php.

Ignoring configuration (overwrite protection)

Sometimes developers will want to protect certain configuration items in the database from ever being overwritten. For example imagine a site named Awesome Site, with a module that supplies the core of the site, named awesome_core. Since this module provides the core functionality of the site, it should never be disabled under any circumstances, as that would disable the core functionality of the site. In this case, the configuration for this module can be set to be 'ignored'. Any attempts to import ignored configuration from the file system to the active configuration in database will be skipped, and not imported.

Configuration can be ignored using the Config Ignore module. The functionality this module provides is similar to the functionality provided by the Config Readonly module discussed earlier, however the Config Readonly module covers the entire configuration of an environment, while the Config Ignore module allows for choosing configuration that should be protected. This configuration is protected by ignoring it altogether on import.

Configuration can be ignored as follows:

  1. Enable Config Ignore module on all environments.
  2. Navigate to the config ignore UI page, and set the configuration item to be ignored. In the case of preventing the awesome_core module from being disabled, the following would be added:
    core.extension:module.awesome_core Configuration to be ignore is entered one item per line. Wildcards can be used.

This setting will ensure that any attempts to change or remove core.extension:module.awesome_core upon configuration import will be ignored. So if the module is enabled on production, and a developer pushes configuration changes that would uninstall this module, those changes will be ignored, and the module will still be set as enabled after import.

Summary

In this article, we looked at various modules that extend the Configuration API, use cases behind these modules, and how the modules worked. We looked at the Config Readonly module, the Configuration Split module, and the Config Ignore module, and how to use these modules to manage configuration differences between environments. In the next, final fifth part of this series, we will look at configuration management for module developers, and how developers can define the schema for the configuration in modules they develop.

Morpht: Drupal 8 Configuration - Module developers and the API

5 days 9 hours ago
Background

We live in an age of Drupal complexity. In the early days of Drupal, many developers would have a single Drupal instance/environment (aka copy) that was their production site, where they would test out new modules and develop new functionality. Developing on the live website however sometimes met with disastrous consequences when things went wrong! Over time, technology on the web grew, and nowadays it's fairly standard to have a Drupal project running on multiple environments to allow site development to be run in parallel to a live website without causing disruptions. New functionality is developed first in isolated private copies of the website, put into a testing environment where it is approved by clients, and eventually merged into the live production site.

While multiple environments allow for site development without causing disruptions on the live production website, it introduces a new problem; how to ensure consistency between site copies so that they are all working with the correct code.

This series of articles will explore the Configuration API, how it enables functionality to be migrated between multiple environments (sites), and ways of using the Configuration API with contributed modules to effectively manage the configuration of a project. This series will consist of the following posts:

This article will focus specifically on how developers can manage, declare, and debug configuration in their custom modules.

Configuration Schema

Configuration schema describes the type of configuration a module introduces into the system. Schema definitions are used for things like translating configuration and its values, for typecasting configuration values into their correct data types, and for migrating configuration between systems. Having configuration in the system is not as helpful without metadata that describes what the configuration is. Configuration schemas define the configuration items.

Any module that introduces any configuration into the system MUST define the schema for the configuration the module introduces.

Configuration schema definitions are declared in [MODULE ROOT]/config/schema/[MODULE NAME].schema.yml, where [MODULE NAME] is the machine name of the module. Schema definitions may define one or multiple configuration objects. Let's look at the configuration schema for the Restrict IP module for an example. This module defines a single configuration object, restrict_ip.settings:

restrict_ip.settings:
  type: config_object
  label: 'Restrict IP settings'
  mapping:
    enable:
      type: boolean
      label: 'Enable module'
    mail_address:
      type: string
      label: 'Contact mail address to show to blocked users'
    dblog:
      type: boolean
      label: 'Log blocked access attempts'
    allow_role_bypass:
      type: boolean
      label: 'Allow IP blocking to be bypassed by roles'
    bypass_action:
      type: string
      label: 'Action to perform for blocked users when bypassing by role is enabled'
    white_black_list:
      type: integer
      label: 'Whether to use a path whitelist, blacklist, or check all pages'
    country_white_black_list:
      type: integer
      label: 'Whether to use a whitelist, blacklist, or neither for countries'
    country_list:
      type: string
      label: 'A colon separated list of countries that should be white/black listed'

The above schema defines the config object restrict_ip.settings which is of type config_object (defined in core.data_types.schema.yml).

When this module is enabled, and the configuration is exported, the filename of the configuration will be restrict_ip.settings.yml. This object has the keys enable, mail_address, dblog etc. The schema tells what type of value is to be stored for each of these keys, as well as the label of each key. Note that this label is automatically provided to Drupal for translation.

The values can be retrieved from the restrict_ip.settings object as follows:

$enable_module = \Drupal::config('restrict_ip.settings')->get('enable');
$mail_address = \Drupal::config('restrict_ip.settings')->get('mail_address');
$log = \Drupal::config('restrict_ip.settings')->get('dblog');

Note that modules defining custom fields, widgets, and/or formatters must define the schema for those plugins. See this page to understand how the schema definitions for these various plugins should be defined.

Default configuration values

If configuration needs to have default values, the default values can be defined in [MODULE ROOT]/config/install/[CONFIG KEY].yml where [CONFIG KEY] is the configuration object name. Each item of configuration defined in the module schema requires its own YML file to set defaults. In the case of the Restrict IP module, there is only one config key, restrict_ip.settings, so there can only be one file to define the default configuration, restrict_ip/config/install/restrict_ip.settings.yml. This file will then list the keys of the configuration object, and the default values. In the case of the Restrict IP module, the default values look like this:

enable: false
mail_address: ''
dblog: false
allow_role_bypass: false
bypass_action: 'provide_link_login_page'
white_black_list: 0
country_white_black_list: 0
country_list: ''
 

As can be seen, each of the mapped keys of the restrict_ip.settings config_object in the schema definition are added to this file, with the default values provided for each key. If a key does not have a default value, it can be left out of this file. When the module is enabled, these are the values that will be imported into active configuration as defaults.

Debugging Configuration

When developing a module, it is important to ensure that the configuration schema accurately describes the configuration used in the module. Configuration can be inspected using the Configuration Inspector module. After enabling your custom module, visit the reports page for the Configuration Inspector at /admin/reports/config-inspector, and it will list any errors in configuration.

The Configuration Inspector module errors in configuration schema definitions

Clicking on 'List' for items with errors will give more details as to the error.

The 'enable' key has an error in schema. The stored value is a boolean, but the configuration definition defines a string

Using the Configuration Inspector module, you can find where you have errors in your configuration schema definitions. Cleaning up these errors will correctly integrate your module with the Configuration API. In the above screenshot, then type of data in the active schema is a boolean, yet the configuration schema defines it as a string. The solution is to change the schema definition to be a boolean.

Summary

In this final article of this series on the Drupal 8 Configuration API, we looked at configuration schema, how developers can define this schema in their modules and provide defaults, as well as how to debug configuration schema errors. Hopefully this series will give you a fuller understanding of what the Configuration API is, how it can be managed, and how you can use it effectively in your Drupal projects. Happy Drupaling!

Morpht: Debugging Guzzle HTTP request errors in Drupal

5 days 9 hours ago

Guzzle makes HTTP requests easy. When they work, it's like magic. However, as with all coding, getting something to work requires debugging, and this is where the Drupal implementation of Guzzle has a major usability problem - any returned messages are truncated, meaning that with the default settings, error messages that can help debug an issue are not accessible to the developer. This article will show developers how they can re-structure their Guzzle queries to log the full error to the Drupal log, instead of a truncated error that does not help fix the issue.

Standard Methodology

Generally, when making a Guzzle request, it is made using a try/catch paradigm, so that the site does not crash in the case of an error. When not using try/catch, a Guzzle error will result in a WSOD, which is as bad as it gets for usability. So let's take a look at an example of how Guzzle would request a page using a standard try/catch:

try {
  $client = \Drupal::httpClient();
  $result = $client->request('GET', 'https://www.google.com');
}
catch (\Exception $error) {
  $logger = \Drupal::logger('HTTP Client error');
  $logger->error($error->getMessage());
}

This code will request the results of www.google.com, and place them in the $result variable. In the case that the request failed for some reason, the system logs the result of $error->getMessage() to the Drupal log.

The problem, as mentioned in the intro, is that the value returned from $error->getMessage() contains a truncated version of the response returned from the remote website. If the developer is lucky, the text shown will contain enough information to debug the problem, but rarely is that the case. Often the error message will look something along the lines of:

Client error: `POST https://exaxmple.com/3.0/users` resulted in a `400 Bad Request` response: {"type":"http://developer.example.com/documentation/guides/error-glossary/","title":"Invalid Resource","stat (truncated...)

As can be seen, the full response is not shown. The actual details of the problem, and any suggestions as to a solution are not able to be seen. What we want to happen is that the full response details are logged, so we can get some accurate information as to what happened with the request.

Debugging Guzzle Errors

In the code shown above, we used the catch statement to catch \Exception. Generally developers will create a class that extends \Exception, allowing users to catch specific errors, finally catching \Exception as a generic default fallback.

When Guzzle hits an error, it throws the exception GuzzleHttp\Exception\GuzzleException. This allows us to catch this exception first to create our own log that contains the full response from the remote server.

We can do this, because GuzzleException provides the response object from the original request, which we can use to get the actual response body the remote server sent with the error. We then log that response body to the Drupal log.

use Drupal\Component\Render\FormattableMarkup;
use GuzzleHttp\Exception\GuzzleException;
try {
  $response = $client->request($method, $endpoint, $options);
}
// First try to catch the GuzzleException. This indicates a failed response from the remote API.
catch (GuzzleException $error) {
  // Get the original response
  $response = $error->getResponse();
  // Get the info returned from the remote server.
  $response_info = $response->getBody()->getContents();
  // Using FormattableMarkup allows for the use of tags, giving a more readable log item.
  $message = new FormattableMarkup('API connection error. Error details are as follows:@response', ['@response' => print_r(json_decode($response_info), TRUE)]);
  // Log the error
  watchdog_exception('Remote API Connection', $error, $message);
}
// A non-Guzzle error occurred. The type of exception is unknown, so a generic log item is created. catch (\Exception $error) {
  // Log the error.
  watchdog_exception('Remote API Connection', $error, t('An unknown error occurred while trying to connect to the remote API. This is not a Guzzle error, nor an error in the remote API, rather a generic local error ocurred. The reported error was @error', ['@error' => $error->getMessage()));
}

With this code, we have caught the Guzzle exception, and logged the actual content of the response from the remote server to the Drupal log. If the exception thrown was any other kind of exception than GuzzleException, we are catching the generic \Exception class, and logging the given error message.

By logging the response details, our log entry will now look something like this:

Remote API connection error. Error details are as follows:

stdClass Object (
  [title] => Invalid Resource
  [status] => 400
  [detail] => The resource submitted could not be validated. For field-specific details, see the 'errors' array.
  [errors] => Array (
    [0] => stdClass Object (
      [field] => some_field
      [message] => Data presented is not one of the accepted values: 'Something', 'something else', or another thing'
    )
  )
)

* Note that this is just an example, and that each API will give its own response structure.

This is a much more valuable debug message than the original truncated message, which left us understanding that there had been an error, but without the information required to fix it.

Summary

Drupal 8 ships with Guzzle, an excellent HTTP client for making requests to other servers. However, the standard debugging method doesn't provide a helpful log message from Guzzle. This article shows how to catch Guzzle errors, so that the full response can be logged, making debugging of connection to remote servers and APIs much easier.

Happy Drupaling!

Image credit: Marco Verch https://www.flickr.com/photos/[email protected]/35337269544

Morpht: Announcing personalisation for Drupal 8 with Recombee

5 days 9 hours ago

At Morpht, we have been busy experimenting and building proof-of-concept personalisation features on Drupal 8. We started off with content recommendations as one of the cogs in a personalisation machine. Recombee stood out as a great AI-powered content recommendations engine and we decided to develop some contributed modules to integrate it with Drupal.

We have implemented three modules which work together:

  • Search API Recombee indexes content and pushes it across to Recombee.
  • Recombee module tracks users and displays recommendations.
  • JSON Template module defines a plugin system for transformers and templates and controls how JSON can be transformed client side.

The video below is a demonstration of these three modules and how they combine to deliver a power recommendations system capable of providing content to anonymous and logged in users alike. 

Download the slides from the presentation
(PDF 785KB)

Let's talk

Find out how personalisation can help you increase audience engagement and lift user experience.

Contact us

ADCI Solutions: 7 must-have practices for a successful e-commerce store

5 days 9 hours ago

Smart search, video shopping, one-click purchase, flawless main page – these and other solutions allow good eCommerce websites to bring profit to their owners in a manner which is graceful and makes the buyer happy. The examples of such websites and many years of practice helped us to identify several time-proven and effective web design solutions.

You can find the link here

1xINTERNET blog: Drupal User Group meetings during a global pandemic

5 days 10 hours ago
During last year, we have had to find other ways to meet with fellow Drupal friends, to share knowledge and inspire each other. The people from Drupal Austria had the idea of the first Drupal D-A-CH online meeting. All German, Austrian and Swiss Drupal communities were invited to join the first monthly Drupal D-A-CH online meeting and it was a great success.

Specbee: A Simple Guide to a Drupal 7 to Drupal 8 (or 9) Migration from a Database Source

5 days 11 hours ago
A Simple Guide to a Drupal 7 to Drupal 8 (or 9) Migration from a Database Source Santhosh Kumar 06 Apr, 2021 Top 10 best practices for designing a perfect UX for your mobile app

If you are a Drupal website owner, developer, admin or a user, you should already know that Drupal 10 is coming soon - June 2022. And that’s just over a year to go! The advantages of migrating to the most updated version of a software are priceless. More so when you have a community of open-source enthusiasts working towards a single goal of improving Drupal every single day, you must trust that migrating to the latest version of Drupal is going to be one of the best decisions you will make.

If you’re still on Drupal 7, it’s about time to migrate to Drupal 8 (or 9). There are many ways of migrating your website from Drupal 7 to Drupal 8 (or Drupal 9). Here’s a no-frills guide to migrating your Drupal 7 website from a database source.

What is a Drupal Migration?

Migration is a movement of content from Drupal 7 to Drupal 8 (or Drupal 9). This includes configuration (content types, vocabularies, user roles, file types, image styles, etc.) and contents (users, nodes, paragraphs, taxonomy terms etc.)

The ETL Process

No matter what your source or destination is for a migration, a Drupal migration will follow the ETL process or the Extract – Transform – Load process. The first step is the Extraction step where the data is extracted from the source plugin. The next step is the Transformation step where the extracted data is processed according to the requirements by the process plugin. And lastly, the Loading step where the data is loaded into the storage by the destination plugin.

Migration Plugins and Modules     1. Source plugin

A set of data, called row from the source. They help fetch data from the source like a database, CSV, XML or JSON.

    2. Process plugin

Row data will be processed and transformed as required. It describes how the destination is to be built from the source data.

    3. Destination plugin

Once processed, the transformed row is saved to the destination in the Drupal site.

Modules Required
  • Migrate Module – Contains APIs to migrate content and configuration to Drupal 8.
  • Migrate Drupal Module – Helps in migrating content and configuration from a Drupal source site to Drupal 8.
  • Migrate Drupal UI Module – A user interface to perform the migration.
  • Migrate plus Module – Provides capabilities to transform source data and APIs for grouping migrations.
  • Migrate tools Module – A contributed module that offers extended drush commands to manage Drupal 8 migrations. 
  • Drupal upgrade – A contributed module used to create the migration YML scripts.
Groundwork Before Diving In

Now that we have a fairly good understanding of some of the basic migration concepts and have installed the basic modules needed for the migration (as discussed above), let’s look at a few simple steps to follow before actually commencing a Drupal 7 to Drupal 8 migration:

  • Audit the Drupal 7 site for contributed modules. Many of the fields in the Drupal 7 content types will depend on contributed modules. So, we will need to check for those modules and install the same in Drupal 8 or Drupal 9.
  • Install the contributed modules if it is not incorporated in Drupal 9 core.
  • Install the supportive core modules like revisions, translations, etc. if needed.
  • Have the Drupal 7 database and files accessible by the Drupal 9 instance.
  • Select the method of migration Bulk or Individual carefully based on the complexity of the site.
Connecting to the Drupal 7 Database

Now we will need to connect to the source database of the Drupal 7 website. For that, we will need to add the source database information in the Drupal 8 or Drupal 9 settings file.

Go to settings.php file of your Drupal 8(or 9) site and add the database with migrate key and run this command:

drush migrate-upgrade --configure-only --legacy-db-key=migrate -- legacy-root=https://www.drupal7.com/

Or you could also directly configure using this URL:

drush migrate-upgrade --configure-only --legacy-db-url=mysqli://[email protected]:33067/drupal7_db -- legacy-root=https://drupal7.com/

The above commands will generate migration YMLs based on the Drupal 7 configuration and contents. It will not start the migration as we added the option “--configure-only”.

Drupal 7 to Drupal 8 Migration - Bulk import

To perform a bulk migration on all configurations and contents to Drupal 8 or 9, you will need to execute these commands :

drush migrate:import --tag=Configuration --execute-dependencies

This will run all the configuration migrations by running the dependencies at first.

drush migrate:import --tag=Content --execute-dependencies

This command will run all the content migrations by running the dependencies at first. Please Note: The migration order is important.

Please Note: The migration order is important.

Drupal 7 to Drupal 8 Migration - Individual import

Sometimes, you might not want to migrate ALL of your content of configurations at one shot. You can then opt to migrate them individually. However, you will need to keep in mind to migrate them in order.

  1. Configuration: User roles, vocabularies, content types, image styles, fields, field instances etc.
  2. Content: Files, paragraphs, Users, terms, nodes, etc.
Migration Tools drush Commands

The Migration Tools module (as discussed previously) is a contributed module that gives you some tools and commands that will help you during a migration. Some of the commands include:

  • drush ms - Migration status
  • drush mim - Migration import

                      Imports the data from Drupal. We can also run the import with a limit. For example: drush mim --limit=10

  • drush mr - Migration rollback
  • drush mmsg - Migration message

                     Shows the captured message (error or notice) after the migration import.

 

A Drupal 7 to 8 migration can be easily performed with Drupal’s core migrate modules itself. Other contributed modules like Migration Tools will provide more flexibility while running the migrations. Core migration API is extremely powerful and we can migrate any kind of content provided by the ETL plugins. Drupal’s flexibility also allows us to create our own custom plugins to achieve any custom migrations. Need assistance in migrating your Drupal 7 website to Drupal 8 or Drupal 9? We would love to help!

Drupal 7 Drupal 8 Drupal 9 Drupal Development Drupal Planet Drupal Tutorial Shefali ShettyApr 05, 2017 Subscribe For Our Newsletter And Stay Updated Subscribe

Leave us a Comment

  Shefali ShettyApr 05, 2017 Recent Posts Image A Simple Guide to a Drupal 7 to Drupal 8 (or 9) Migration from a Database Source Image Exposing Your API in Drupal 8 - A brief tutorial Image The Most Effective Methods to Overcome Software Vulnerabilities Want to extract the maximum out of Drupal? TALK TO US Featured Success Stories

A Drupal powered multi-site, multi-lingual platform to enable a unified user experience at SEMI.

link

Discover how our technology enabled UX Magazine to cater to their massive audience and launch outreach programs.

link

Discover how a Drupal powered internal portal encouraged the sellers at Flipkart to obtain the latest insights with respect to a particular domain.

link

OpenSense Labs: Achieving the perfect SEO in Drupal : 2021 Guide

5 days 13 hours ago
Achieving the perfect SEO in Drupal : 2021 Guide Akanksha Mehta Tue, 04/06/2021 - 14:42

SEO is the process of optimising a website's content with the use of certain keywords with the goal of ranking better in the search results of a search engine, for example, Google. SEO is independent of PPC (pay-per-click) results, and focuses on organic rankings. If a business wants to make the most of the web to reach its targeted audience, Search Engine Optimisation is one aspect that cannot be ignored. According to Backlinko, less than 1% of users care to explore beyond the first page of Google.

Source : Backlinko

Website content still relies heavily on SEO for traction, legitimised by a recent survey stating that several bloggers found that SEO was the second most important driver of traffic for their websites.

Source : Backlinko

Owing to these parameters, Drupal has taken into account to include several modules to facilitate SEO in Drupal. Not only are there multiple intent SEO friendly features, Drupal also provides several customizations to fit into the trajectories of various kinds of businesses online.

The Drupal SEO Checklist 

Here are some must have SEO modules in Drupal.

For the overall framework
  • Real Time SEO for Drupal acts as a constant alarm clock to remind you of things that you might have missed. Since there are a number of technicalities involved in SEO, one might skip one or two if left unassisted. Real time SEO keeps a track of things like post length, meta description, consistency of the focus keyword and its placement in the appropriate places etc.
  • Drupal’s SEO checklist module makes use of best practices to check your website for proper optimisation.. It automates most of the on page optimisation making use of the latest techniques that are updated in the module regularly. The way it functions is by breaking down the tasks into functionalities like Title Tags, Paths, Content etc. Links to the associated modules are attached against the task. It also keeps a track of the entire SEO history by placing a time stamp next to each saved item. The SEO checklist module, however, is not for newbies as it requires the user to know the basics of SEO to make optimum use of it. 
  • The Require on Publish module is best to use in cases where the content has fields such as tags or SEO data that one doesn't really need to fill in until the content is going to be published. Hence, it marks required only when the fields are actually required in the process, and not before that. 
  • One of the most popular ways of trapping and practicing SEO is to use Google Analytics to look for the trending keywords and then incorporating those in your content. The Google Analytics module allows a number of statistical features to be added to your website like domain tracking, AdSense support, Modal dialog tracking, enhanced link attribution support etc. thus forming an extensive web statistics tracking system for the site. Additionally, you could also use the Googalytics module that provides for integration of Google Analytics in Drupal.
Linking it Right
  • Linkit provides a simple interface for internal and external linking with WYSIWYG (What You See Is What You Get) editors with the help of an autocomplete field. This module has, by default, support for all types of entities that define a link template, for example, taxonomy, nodes, files, comments etc. Linkit, however, does not have support for link attributes like title, class or target and one would have to use the Editor Advanced Link for the purpose.
  • The Link checker module does exactly what its name suggests. It extracts links from one's content and then at regular intervals, tries to detect broken hypertext links by checking the sites and evaluating the HTTP response codes. If a link check fails, it shows it in the separate section on the content page, hands making it extremely simple to rectify any errors.
  • The Footnotes module creates automatically numbered footnote references in the content, making the article look better structured.
  • The Redirect module provides the user the ability to create manually redirects for all the content, while also maintaining a canonical URL for it - hence redirecting all other requests to that path.
  • Pathauto could also be used in such a case to automatically generate the URL aliases and path redirects, to ensure that the changes in the URL alias do not break the existing links. 
For Navigation
  • The Easy Breadcrumb module is a navigation tracker, which when embedded in your pages, utilises data from the work you have already done to generate your paths' alias. It is a plug and play module that auto generates the breadcrumb by using the current URL. 
  • On the other hand the Menu Breadcrumb module allows the user to use the menu that the current page belongs to for the breadcrumb. It uses the titles of the parent menus to generate the breadcrumbs.
Sitemap
  • Sitemap module helps  make navigation user friendly by providing the visitors a sitemap that gives them an overview of the entire site. It also has provisions for displaying the RSS (Really Simple Syndication) feeds for all the blogs and also for the various categories to explore within the site.
  • To generate a sitemap a Simple XML Sitemap can also be used. The sitemaps generated by this module are compliant to Google's standard regarding multilingual content and are also good with respect to SEO in Drupal.
  • The XML Sitemap module takes into account the sitemaps.org specifications, while creating sitemaps, helping search engines like Google, Ask and Yahoo! to better understand and place the website.
  • Using Menu Attributes, one can specify additional attributes for items in a menu such as ID, name, class etc. The user wants to give the menu and ID so that it is easily detectable using jQuery or when you want to customise the menu. 
For tags
  • Metatag module is quite useful for a methodical Search Engine Optimisation. It auto generates structured metadata like meta tags, meta description and meta keywords that help improve the overall ranking of the website in the search engine results.
  • Hreflang tags are used by search engines to serve the correct language or regional URLs in the search results. Once these tags are generated, the Hreflang module automatically adds these tags to the respective pages. 
  • The Schema.org Metatag module could be used to further extend the Metatag module to display data in a structured format in the head of web pages.
  • The Power Tagging module is used to extract the content of your entity, like node or user, and offer you the concepts and existing free terms that fit best in the context. It has the provision of tagging the entire content automatically via bulk tagging, and also supports multilingual tagging.
  • Similar By Terms brings out the similarities in content items based out of taxonomy terms and links assigned to the content, making the site easily navigable.
Combat Error 404

Instead of displaying '404 page not found', the Search 404 module performs a search on the existing keywords in the URL. This helps retain visitors who might happen upon outdated links.

These are some of the major search engine optimisation modules that help Drupal websites achieve optimum SEO, whether directly or indirectly. While the software is constantly evolving to adapt to the changing norms, SEO remains too dynamic of a subject. And with constant parallel innovation in the terms of technology, SEO also keeps undergoing significant changes owing to these trends. Some Optimisation trends that are projected to stay afloat in 2021 are listed below.

SEO trends in 2021 Looking for user’s search intent 

As User experience expands and seeps into different arenas, its effect is bound to be seen in SEO as well. Google has been pretty mindful about making search intent a top priority, ie, the search engine aims to display results regarding the search intent of the user. To figure out the search intent, it is imperative to examine the keyword. The intent might be informational, transactional, commercial or navigational. For example, a person that searches for 'buy protein bars' has a transactional intent, and tracking this, the search engine is likely to redirect the person to an online shopping site or a grocery store nearby. But if the person searches for 'best protein bars', the search results will greatly vary, leading him to a blog or an informational website.

Source : Search Engine LandCustomer Retention

Not just customer acquisition, but retention also needs to be considered while planning out the SEO of a website. When a visitor turns up, you should be interacting with them, answering their questions, and every need that they are searching for. Each keyword that has been used in optimisation of the site should be justified, and there should be appropriate information about it.

Brand SERP Optimisation

SERP (Search Engine Result Page) tracking is projected to become the norm in 2021. This means that brands will go the extra mile to define who they are and what they offer in accordance with Google's Passage Ranking. The SERP layout is projected to undergo change as well, with businesses switching from creating several verticals within the website for different topics to creating long pages for the entire content, for better ranking in the search results. 

For this to formulate, we may see more personalized research on consumer behaviour in 2021.

Core Web Vitals

Core Web Vitals include features like page speed, multiple device friendliness, image optimisation in  different devices, compliance to security protocols etc. Google introduced core web vitals as a ranking factor in 2021. Hence, it is another aspect that needs to be considered while optimising a website. SEO now is not just about whether it answers your users' queries but also about how satisfied the user is with that information and also whether the environment in which it is being presented seems trustworthy. 

Importance of mobile SEO

About 56% of global internet traffic in 2021 has been attributed to be coming from mobile devices, hence while planning out optimisation strategies, the primary area of concern should be the performance of your website when accessed from a smartphone. Hence, a bare minimum mobile experience isn’t going to suffice if you want Google to consider your website setting out the ranking.

Web Automation

The quality as well as quantity of AI (Artificial Intelligence) generated content cannot be beaten, and hence it is expected to increase monumentally in the following year. Jesse Mcdonald, Optimisation Lead at IBM, believes that it is going to be one of the biggest SEO trends in 2021 to roll out automated functionalities with respect to optimisation, cutting down manual SEO wherever possible. 

Content is still the king

It has been witnessed that blogs of over 2000 words outperform blogs of 1000 words or less, the former perform better with respect to Google's E-A-T (Expertise, Authoritativeness, Trustworthiness) guidelines. Hence, the long form content trend is to continue in 2021 as well, as most websites try to expand their content to said length.

Content also has immense potential when it comes to expanding the audience base of the article. One sure shot way of getting yourself some subtle marketing is to include some statistics, survey or study that constitutes research related to the topic, as others writing on the same topic will keep linking you in their document while using your research data.

Graphics do the job of grabbing attention really quick, hence visual content should be added at regular intervals for sustaining the reader’s attention. Concept visuals, i.e., visuals that explain tricky concepts are especially helpful and are more likely to be shared and referred to. 

Lastly, all the constant research that is done over topics from time to time can be brought to good use by presenting a bunch of content on a specific topic as a ‘hub’. These work exponentially well for SEO, and also are a form of value rich content that is likely to grab attention in a good way and be shared widely.

Visual Search

With the popularity of Google lens soaring, visual search has been trending throughout the year and will continue to occupy space in 2021 trends as well. Therefore, optimising images on your website has become as essential, as according to Backlinko, as 32.5% pages that ranked in Google Lens had a keyword in their Title tag that matched Google's Vision Label.

Conversational UI: Voice and Video interfaces

Google Home and Alexa how become the new members of most internet connected households today, simply because the added convenience these devices bring with themselves. This is the reason why Search Engine Optimisation for voice search is not an option to consider anymore - it is quite a necessity. With Google and Alexa constantly referring to sites that consist of the user's question and answer both, FAQ lists are becoming more and more important. According to Google, 4 out of 10 US adults perform at least one voice search in a day. 

Videos are a significant element that are driving significant traffic to websites, as demonstrated by the following graph.

Source : Orbit Media Studios 

With a dedicated social media platform just for videos (YouTube), the change is quite inevitable and was bound to happen. Video Optimisation is the future of SEO today, hence keyword optimisation needs to be done in the multimedia of your site as well.

Featured Snippets 

Google's search results have become smart as well. With increased focus on User experience, the search engine realises that it is pretty inconvenient for a user to click on every website to read the contained content. So it displays the related content in the form of a Q&A as a part of its featured snippets.

Backlinks

Creating backlinks can also effectively improve SEO rankings and drive traction to the site, but this can only be achieved when the content is good enough to quote, or already has a good enough SEO or an online presence in order to be tracked by other websites. Guest posting is another way of tapping into backlinks. 

Google Passage Ranking

Similar to Featured Snippets, Google has also started to run specific passages from websites that appear relevant to the search result. Google also specified that this feature does not mean that the passages are assessed independently of their pages, but simply means that specific paragraphs can also be an additional ranking factor from now on. 

Domain Authority

With E-A-T evaluation setting in, domain authority is less about links and more about this part of the guideline now - as Google says that it wants to rank pages that are 'reliable sources' and appear to have content that is reflective of the qualities of 'expertise, authoritativeness and trustworthiness'. 

  • Creators of the content of the page are taken into account - is the content generated at random by freelancers, or are these people experts in the particular topic? 
  • A suspicious looking website will not rank well on Google's search results, as the notions of transparency and accountability are gaining ground widely.
  • Maintaining a good reputation outside of a website is also equally important. There is nothing worse than your website claiming something and external sources disagreeing with it. Similarly, being cited on other websites on a positive note is considered while ranking as well.
Combating decreasing CTRs

It is common knowledge that organic click-through-rates are down. And yet it comes as no surprise, because it is quite difficult for organic to survive among features like SERP, Ads, and others. There is a way to combat this practice and stand out, even though a little, in this race - and that is by creating keyword rich URLs, as they have been shown to get much more clicks than URLs without the keyword that the user has searched for.

Conclusion

Even after 20 years of its conception, Drupal continues to remain a favourite in website creation, and that is primarily due to its high level of customisation and adaptability to the present trends. Today we see individuals and organisations both contributing to and relying on Drupal because it has a solid foundation of what it takes to stay up to date, even when it comes to SEO - through its extensive modules and distributions. Rest assured, come what may, the community stands prepared to make the most of these upcoming trends.

blog banner blog image drupal seo modules drupal seo checklist seo trends Blog Type Articles Is it a good read ? On

hussainweb.me: My advice to my younger self (and to new Drupal developers)

5 days 18 hours ago
I recently opened up a spreadsheet where people can put in their ideas of what I can write about in this DrupalFest series. Someone put in a topic of what advice I would give my younger self. This idea intrigued me and I thought I will make an attempt at writing down advice to new Drupal developers. I am not very comfortable presuming that someone would want to take advice from me; so I am going to say what I would want my younger self to know.

Evolving Web: Help Someone Get Started With Drupal! [Free guide]

6 days 5 hours ago

At Evolving Web, we love getting people excited about using Drupal. If you know someone who’s about to take their first steps with our favourite open-source CMS, we want to help you help them get started!

Our newest ebook is the perfect introduction to what Drupal is all about and what you can build with it, complete with a practical glossary and a list of essential resources to learn more. We also have a ton of videos, articles, and other content you can share with your favourite Drupal beginners—plus some tips on in-depth training. Here’s an overview.

📚 Download ebook: Get started with Drupal

Why did we put together our Get started with Drupal guide?

There are lots of great Drupal resources out there, and ours certainly isn’t the only beginner’s guide around. However, we really did our best to make our Get started with Drupal ebook as straightforward and value-dense as possible.

The guide was originally created as a supplement to the Getting the most out of Drupal session hosted by our co-founder Suzanne during MidCamp 2021, and it stands alone as a practical and accessible Drupal 101 that covers all the essentials. 

Who is it for?

Get started with Drupal is an ideal starting point for virtually anyone who wants to, well, get started with Drupal—even people with no development experience.

If your organization is looking to adopt Drupal, for example, your developers aren’t the only ones who’ll be affected—web managers, marketers, content creators and more should all have a good understanding of the system’s basics.

What’s inside?

Get started with Drupal introduces all the key concepts and terms required to start building a deeper understanding of Drupal.

Here are the book's main sections:

  • Why not build a website from scratch? A quick intro to the concept of content management systems and the balancing act between flexibility and ease of use.
  • Drupal 101. This section should definitively answer the “what is Drupal, anyway?” question.
  • Overview of Drupal functionality. A look at the real-life things you can do with Drupal.
  • Key Drupal terminology. The essential dictionary of Drupal: all the niche terms you’ll come across when reading about the system.
  • Planning your Drupal project. Tips and best practices to set yourself up for success before you start to use Drupal on your live site, including a role-based list of skills your team will need to succeed.
  • Adopting Drupal. Valuable lessons we’ve learned over the years by helping organizations use Drupal to its full potential. 
  • Resources. Some fodder for your bookmarks folder. 
What if we need more in-depth training?

We can help with that, too! One of our biggest missions at Evolving Web is to empower teams who work with Drupal, and one of the ways we accomplish this is by sharing our knowledge with the community.

First, be sure to check out our Resources page, where you’ll find our growing library of on-demand webinars, ebooks, white papers, and more. Next, there’s also our blog (and one of our side projects, the Drupal feed aggregator Drupal Sun) and, if you prefer watching your Drupal content, our YouTube channel.

Paid training

Sometimes self-directed learning has its limits. If you’re looking for a more structured curriculum, take a look at our upcoming courses.

Our Drupal training programs combine live online learning and office hours with take-home exercises you can do at your own pace. Plus, completing one of our courses gives you an official Evolving Web Learn Drupal certification to officialize your new skills. 

Share your Drupal journey with us!

If you’ve successfully introduced someone to Drupal—with or without our handy beginner’s guide—we’d love to hear from you. Send us a tweet @EvolvingWeb!

+ more awesome articles by Evolving Web

Tag1 Consulting: A Deep Dive Into End To End Encryption (E2EE) in Yjs - Part 1

6 days 8 hours ago

In today’s electronically driven communication world, data security is no small matter. What’s safe? Who do you trust? Who else can access your data, and do you even know who those people or companies are selling it to? A critical part of data security is encryption. It protects everything from our personal information, helping prevent identity theft, financial information like your bank account and credit card from being accessed, to company secrets. According to a 2019 CNBC article, cyberattacks cost businesses an average of $200,000, with 43% of attacks being aimed at small businesses. What can your business do to help ensure your data is protected, while still enabling collaboration? Take a deep dive into understanding end to end encryption, and how emerging technologies like Yjs can be incorporated to meet your needs. Tag1 Managing Director Michael Meyers and VP of Software Development Fabian Franz are joined by Yjs creator Kevin Jahns, and Nik Graf, a technology consultant and creator of Serenity Notes in this Tag1 Team Talk. ### Related content - Serenity Notes - Yjs - Index of Yjs resources on Tag1 Photo by Philipp Katzenberger on Unsplash

Read more [email protected]… Mon, 04/05/2021 - 07:21

hussainweb.me: Code Quality check tools for Drupal

6 days 18 hours ago
This is the fourth post in my DrupalFest series and I am excited to keep it going. I want to write about different tools I am aware of for running quality checks on Drupal code. This will be somewhat similar to my last post where I presented various options but focused on the method I use nowadays.

#! code: Drupal 9: Some Strategies For Developing Update Hooks

1 week ago

Drupal's update hook system is a powerful way of updating your site to introduce things that wouldn't be handled using the configuration system.

Modules will use update hooks to bring sites that have the old version of the module in line with the latest additions to the module. For example, if a new field is added to a table that the module uses then an update hook will be needed to add that field to all sites that are current using the old version. This update hook will be in addition to the install hook that would install the table with the added field in the first place.

There are a number of different reasons why you would want to use update hooks on your own site. Normally being stored in either install profiles or custom modules they would be run on deployment in order to update your dev/stage/production site with changes without having to manually apply them. This is a useful way to do one of the following actions.

Read more.

Checked
1 hour 44 minutes ago
Drupal.org - aggregated feeds in category Planet Drupal
Subscribe to Drupal Planet feed