Drupal News

OSTraining: OSTips - E-Commerce Inside Drupal Made Easy

Main Drupal Feed - Fri, 10/09/2020 - 15:10
How would you like to be able to set up an ecommerce platform on your drupal site in less than 60 seconds? You can!   In this video, I want to share with you my little frustration with drupal and drupal e-commerce. It's really hard to set up!  However,  there's a fantastic e-commerce platform called ecwid that allows you to set up your store in no time.  Then you can literally have it embedded on your Drupal site in less than 60 seconds. People will never know the difference, because everything stays on your Drupal site!   Let's check it out.

Third & Grove: Acquia Engage 2020 Award Nominations

Main Drupal Feed - Fri, 10/09/2020 - 09:26

Third and Grove is honored to have three clients making the final round for the Acquia Engage 2020 awards.

Mateu Aguiló: A standard for progressive decoupled Drupal

Main Drupal Feed - Fri, 10/09/2020 - 00:00
In this video I show a set of Open Source tools we have created to manage the whole application lifecycle when embedding JS apps inside of Drupal. You can fork these tools, and with a couple of clicks you will get a demo of progressive decoupling in Drupal in your own site. This works in Drupal 8 and Drupal 9.

Chapter Three: Local Behat Testing with Lando and Pantheon

Main Drupal Feed - Thu, 10/08/2020 - 19:06

If you've followed Pantheon's Build Tool Instructions and used Pantheon's Example Drops 8 Composer as the base to take advantage of CircleCI then you've encountered Behat tests. Behat tests are extremely valuable for testing site functionality before new code goes to production or a shared code stream. However, on a custom site these default tests provided by Pantheon are likely to fail if you've made even a benign change like deleting Tags vocabulary on a Drupal standard installation.

Vardot: CMS Buyers Guide

Main Drupal Feed - Thu, 10/08/2020 - 13:26
CMS Buyers Guide Type Tool/Template Firas Ghunaim Thu, 10/08/2020 - 16:26

 

At the core of any successful digital transformation is finding the ideal CMS that best fits your enterprise short and long-term digital objectives.

However, this decision making process can take a lot of time and effort.

To simply this process, our team developed this guide to help you identify the CMS that best suits your enterprise and your end-users based on the criteria that is relevant to your business requirements.

The CMS Buyers Guide will feature:

  • Vendor and product viability
  • Budget concerns
  • CMS capabilities
  • Best practices and standards
  • ... and much more.

Download the CMS Buyers Guide by filling out the form to the right.

Form Form title Download Now Solutions by industry Media and Entertainment Healthcare Financial Services High Tech Travel and Tourism Retail Higher Education Government Solutions by need Enterprise CMS Drupal Managed Services E-Commerce On-Site SEO Knowledge Management Social Business Community Related services Web Development Support and Maintenance Drupal Migration and Upgrades DevOps and Engineering Digital Marketing UI/UX Design Digital Strategy Product Varbase Uber Publisher Marketing Automation Open Social

OSTraining: Control Spam in Drupal with Honeypot and/or Antibot

Main Drupal Feed - Thu, 10/08/2020 - 04:00

From its conception, the fundamental (ground) idea of the internet was the exchange of information through code snippets of a markup language. This is still the ground principle that moves the internet these days. There are, of course, a lot of other things you can do over the internet, but it all comes down to an exchange of information.

With this kind of freedom, it is not surprising, that people abuse this for their own benefit. Spam comments are a form of abusing this privilege.

The combination of the Drupal modules Honeypot and Antibot will ensure that your site is “almost” 100% protected from spam (at least the ones produced by robots).

Keep reading to learn how to Control Spam in Drupal with Honeypot and/or Antibot!

PreviousNext: Stop your builds failing with git pre commit hooks

Main Drupal Feed - Wed, 10/07/2020 - 23:48

Have you ever happily pushed your latest piece of work ready for others to test only to have it fail the build on coding standards? If so, git pre commit hooks could be your friend!

by saul.willers / 8 October 2020

It's pretty standard practice these days for CI build pipelines to include linting steps to ensure things like coding standards pass. Depending on how the build is configured, failing coding standards can result in the entire build failing. 

Because linting is generally not resource intensive, running it locally can be a useful time saver. But it's an easy step to forget. Thankfully it can be automated to run before every git commit with a pre-commit hook.

First we need a script to fire before the commit. This is placed in the project repo somewhere like .git-hooks/pre-commit:

#!/bin/sh

make lint-php
exit $?

We use Makefiles to call our custom lint-php rule, but this could be a Robo command or any other task running which fires your coding standard check.

Next, the script needs to be executable:

chmod +x .git-hooks/pre-commit

Then let git know about this script by running the following command:

git config core.hooksPath .git-hooks

That's it, our coding standards check will now automatically run whenever we do a git commit and stop the commit from proceeding if there is a fail.

If you've got a WIP or something you wish to commit regardless of any errors use git commit --no-verify

Hopefully this saves you from pushing coding standard fails in the future.

Tagged Drupal Development, Git, CI

Promet Source: SEO and Analytics for Zero-Click Searches

Main Drupal Feed - Wed, 10/07/2020 - 21:01
Google  has made gigantic leaps in streamlining search results -- to the point that more than 50% of Google searches no longer result in a click-through to a website or other content. More often than not, search queries and question-based searches can now be answered directly from the Search Engine Results Page (SERP). 

Centarro: Commerce Shipping release adds shipment confirmation emails and improved JSON:API support

Main Drupal Feed - Wed, 10/07/2020 - 19:29

Several months have passed since we've tagged our first Commerce Shipping release candidate, which added support for "billing same as shipping" address copying and resolved a variety of bugs.

Since then we've kept a close eye on the issue queue. Even though it isn't part of the core Commerce project itself, we consider it an essential contributed module in our ecosystem. We've resolved a few more "last mile" bugs and recently packaged the module's second release candidate.

Shipment confirmation emails

Thanks to the hard work of several community contributors, we now support sending a "shipment confirmation" email to notify customers when their ordered items are shipped.

This behavior is controlled by a setting at the shipment type level:

Similar to order receipts, it's also possible to resend the shipment confirmation from an order's shipments tab:

Read more

BADCamp News: Less than a week away from BADCamp liftoff!!

Main Drupal Feed - Wed, 10/07/2020 - 18:29
Less than a week away from BADCamp liftoff!! Wed, 10/07/2020 - 12:00 volkswagenchick Wed, 10/07/2020 - 11:32 We are less than a week away from BADCamp liftoff!! Bay Area Drupal Camp (BADCamp) runs from 9 am - 4 pm PT from Wednesday, October 14 through Saturday, Oct 17. Limited-availability workshops and summits will take place on Wednesday and Thursday. This year we are delivering content in the Hopin platform and separate registration is required for both the workshop and summits block and the sessions. We understand that you may have already registered on the BADCamp website, but we do require folks to register on Hopin as well. Drupal Planet

BADCamp News: Less than a week away from BADCamp liftoff!!

Main Drupal Feed - Wed, 10/07/2020 - 18:29
Less than a week away from BADCamp liftoff!! Wed, 10/07/2020 - 12:00 volkswagenchick Wed, 10/07/2020 - 11:32 We are less than a week away from BADCamp liftoff!! Bay Area Drupal Camp (BADCamp) runs from 9 am - 4 pm PT from Wednesday, October 14 through Saturday, Oct 17. Limited-availability workshops and summits will take place on Wednesday and Thursday. This year we are delivering content in the Hopin platform and separate registration is required for both the workshop and summits block and the sessions. We understand that you may have already registered on the BADCamp website, but we do require folks to register on Hopin as well. Drupal Planet

Mobomo: Debunking 4 CMS Migration Myths

Main Drupal Feed - Wed, 10/07/2020 - 17:25

Here’s a dirty secret: most businesses are unsatisfied with their website. Research shows that 34% of website owners are unsatisfied with the amount of business their website generates for them. Loudhouse data suggests that 62% of business owners believe a more effective website would increase their sales. And millions of business websites deal with slow load times, inconsistent customer experiences, and problematic UI/UX issues.

There’s a reason that 36% of small businesses STILL don’t have a website. Creating an amazing, design-driven, customer-centric website is challenging. So, what do you do when your website isn’t making the cut? You look towards the source — your Content Management System (CMS). Every year, thousands of private and public entities migrate their website to a new CMS.

But, unfortunately, thousands more don’t. Migration is scary. It’s easier to stay with your current CMS and focus on redesigns or new templates. Here’s the problem: new coats of paint don’t fix broken engines. If you’re thinking about migrating from WordPress or Joomla to Drupal, you’ve probably heard rumors and myths regarding migrations.

Let’s clear those up. Here are 4 myths about migration that need to be squashed.

Myth #1: I’m Going to Lose All My Content/Data

This is, by far, the most common excuse against migrating. You’re worried all of that precious content and data are going to fall off the ship if you switch ports. And, you’re right to worry. It could… if you don’t migrate correctly. But it’s not inevitable. You can prevent data and content loss. In fact, if you lose data or content, we would consider that a failed migration. In other words, successful migrations keep data and content intact by definition.

Here are some handy-dandy steps you can take to ensure that your precious data doesn’t go overboard during your migration:

  • Crawl your site before migration and use the crawl data to check for URL issues. If you check each URL, you should be able to see any missing content (and fix it!)
  • Keep your existing site stable until you’ve fully migrated.
  • When you migrate, check for duplicate content; plenty of site owners run into the opposite of losing content.
Myth #2: I Have to Invest in a Redesign

You’re migrating; you might as well invest in a redesign, right? Sure! You could. But it’s tricky. When you do a redesign and a migration, you’re no longer just matching URL-to-URL and content-to-content, you’re simultaneously rebuilding your website. Don’t get us wrong; there are advantages. It’s a great time to redesign from an SEO perspective (you’re already going to take a small hit during the migration; more on this in the next section), but it also requires significantly more planning, budget, and time.

If you want to do a redesign-migration, we heavily recommend that you touch base with your design company. You want to work through the kinks and create a best-in-class action plan to tackle any issues that may (or may not) pop up. The entire migration will be structured around the redesign, so it’s important to carefully weigh your options.

Myth #3: Goodbye SEO!

From an SEO perspective, migration sounds like a nightmare. You’ve worked diligently to build up your SEO. What happens when you frolic to a new location? Let’s get this out of the way: your SEO will take a temporary hit. But, it shouldn’t last long. In fact, there’s a good chance you’re moving to another platform because it’s better at handling SEO. For example, Drupal has built-in SEO capabilities (e.g., title-based URL nodes, customizable meta tags, etc.) WordPress does not. Obviously, you can get SEO plugins for WordPress that help you build SEO functionalities, but most of those plugins are also available for Drupal — so Drupal gives you a net gain.

Here’s a secret: migration can help your page rank. After the first awkward week (Google has to recrawl your website, recognize that it’s you, and give you back your ranking), migration can help you build a more powerful SEO framework.

Want to migrate without dumping your SEO overboard? Here are some tips:

  • Update your internal links
  • Benchmark your Google Analytics profile and compare it with your analytics post-migration to look for gaps
  • Keep any old domains and redirect your website
  • Check for broken or duplicate content that could tank your SEO
  • Manage your sitemaps
  • Update any PPC campaigns and ad creatives
Myth #4: You Just Have to “Lift-and-Shift”

There are plenty of myths surrounding the difficulty of migration. But there are also a few myths making migration out to be super easy. And, without a doubt, the most prevalent “easy-peasy-lemon-squeezy” migration myth is the ever-coveted “lift-and-shift.” There is no one-size-fits-all strategy for migrating websites. Sometimes, it can be as easy as lifting content off of one website and putting it onto another website. But that’s seldom the case.

Generally, you need to set up test servers, check to see if website elements function correctly on the new platform, test out and utilize new CMS features, and a variety of other tasks before you can simply drop content from one place to another. In other words, lift-and-shift may work when you’re migrating a cloud environment, but it often doesn’t work with CMS migration.

Remember, just because everything worked perfectly in one environment doesn’t mean it will in another one. You may have to fix some website elements and carefully construct your new website ecosystem. At the same time, you’ll probably be playing around with the new features available to you on Drupal — so the “lift-and-shift” is usually more of a “lift-and-test-and-shift.”

Do You Need Help With Your Drupal Migration?

At Mobomo, we help private and public entities migrate to Drupal environments using proven migration strategies and best-in-class support. So, whether you’re looking to establish your website in a more secure, SEO-friendly environment or you’re looking to do a redesign-and-migrate, we can help you migrate pain-free. Are you ready to move to a brighter future?

Contact us. We’ve got your back.

The post Debunking 4 CMS Migration Myths appeared first on .

Mobomo: Debunking 4 CMS Migration Myths

Main Drupal Feed - Wed, 10/07/2020 - 17:25

Here’s a dirty secret: most businesses are unsatisfied with their website. Research shows that 34% of website owners are unsatisfied with the amount of business their website generates for them. Loudhouse data suggests that 62% of business owners believe a more effective website would increase their sales. And millions of business websites deal with slow load times, inconsistent customer experiences, and problematic UI/UX issues.

There’s a reason that 36% of small businesses STILL don’t have a website. Creating an amazing, design-driven, customer-centric website is challenging. So, what do you do when your website isn’t making the cut? You look towards the source — your Content Management System (CMS). Every year, thousands of private and public entities migrate their website to a new CMS.

But, unfortunately, thousands more don’t. Migration is scary. It’s easier to stay with your current CMS and focus on redesigns or new templates. Here’s the problem: new coats of paint don’t fix broken engines. If you’re thinking about migrating from WordPress or Joomla to Drupal, you’ve probably heard rumors and myths regarding migrations.

Let’s clear those up. Here are 4 myths about migration that need to be squashed.

Myth #1: I’m Going to Lose All My Content/Data

This is, by far, the most common excuse against migrating. You’re worried all of that precious content and data are going to fall off the ship if you switch ports. And, you’re right to worry. It could… if you don’t migrate correctly. But it’s not inevitable. You can prevent data and content loss. In fact, if you lose data or content, we would consider that a failed migration. In other words, successful migrations keep data and content intact by definition.

Here are some handy-dandy steps you can take to ensure that your precious data doesn’t go overboard during your migration:

  • Crawl your site before migration and use the crawl data to check for URL issues. If you check each URL, you should be able to see any missing content (and fix it!)
  • Keep your existing site stable until you’ve fully migrated.
  • When you migrate, check for duplicate content; plenty of site owners run into the opposite of losing content.
Myth #2: I Have to Invest in a Redesign

You’re migrating; you might as well invest in a redesign, right? Sure! You could. But it’s tricky. When you do a redesign and a migration, you’re no longer just matching URL-to-URL and content-to-content, you’re simultaneously rebuilding your website. Don’t get us wrong; there are advantages. It’s a great time to redesign from an SEO perspective (you’re already going to take a small hit during the migration; more on this in the next section), but it also requires significantly more planning, budget, and time.

If you want to do a redesign-migration, we heavily recommend that you touch base with your design company. You want to work through the kinks and create a best-in-class action plan to tackle any issues that may (or may not) pop up. The entire migration will be structured around the redesign, so it’s important to carefully weigh your options.

Myth #3: Goodbye SEO!

From an SEO perspective, migration sounds like a nightmare. You’ve worked diligently to build up your SEO. What happens when you frolic to a new location? Let’s get this out of the way: your SEO will take a temporary hit. But, it shouldn’t last long. In fact, there’s a good chance you’re moving to another platform because it’s better at handling SEO. For example, Drupal has built-in SEO capabilities (e.g., title-based URL nodes, customizable meta tags, etc.) WordPress does not. Obviously, you can get SEO plugins for WordPress that help you build SEO functionalities, but most of those plugins are also available for Drupal — so Drupal gives you a net gain.

Here’s a secret: migration can help your page rank. After the first awkward week (Google has to recrawl your website, recognize that it’s you, and give you back your ranking), migration can help you build a more powerful SEO framework.

Want to migrate without dumping your SEO overboard? Here are some tips:

  • Update your internal links
  • Benchmark your Google Analytics profile and compare it with your analytics post-migration to look for gaps
  • Keep any old domains and redirect your website
  • Check for broken or duplicate content that could tank your SEO
  • Manage your sitemaps
  • Update any PPC campaigns and ad creatives
Myth #4: You Just Have to “Lift-and-Shift”

There are plenty of myths surrounding the difficulty of migration. But there are also a few myths making migration out to be super easy. And, without a doubt, the most prevalent “easy-peasy-lemon-squeezy” migration myth is the ever-coveted “lift-and-shift.” There is no one-size-fits-all strategy for migrating websites. Sometimes, it can be as easy as lifting content off of one website and putting it onto another website. But that’s seldom the case.

Generally, you need to set up test servers, check to see if website elements function correctly on the new platform, test out and utilize new CMS features, and a variety of other tasks before you can simply drop content from one place to another. In other words, lift-and-shift may work when you’re migrating a cloud environment, but it often doesn’t work with CMS migration.

Remember, just because everything worked perfectly in one environment doesn’t mean it will in another one. You may have to fix some website elements and carefully construct your new website ecosystem. At the same time, you’ll probably be playing around with the new features available to you on Drupal — so the “lift-and-shift” is usually more of a “lift-and-test-and-shift.”

Do You Need Help With Your Drupal Migration?

At Mobomo, we help private and public entities migrate to Drupal environments using proven migration strategies and best-in-class support. So, whether you’re looking to establish your website in a more secure, SEO-friendly environment or you’re looking to do a redesign-and-migrate, we can help you migrate pain-free. Are you ready to move to a brighter future?

Contact us. We’ve got your back.

The post Debunking 4 CMS Migration Myths appeared first on .

Lullabot: Lullabot Podcast: A Look Into the Past, Present, and Future of Lullabot

Main Drupal Feed - Wed, 10/07/2020 - 16:10

Matt and Mike have former CEO Matt Westgate on to talk about his transition to Tugboat, and also speak with new CEO Seth Brown to talk about what's upcoming for Lullabot.

Lullabot: Lullabot Podcast: A Look Into the Past, Present, and Future of Lullabot

Main Drupal Feed - Wed, 10/07/2020 - 16:10

Matt and Mike have former CEO Matt Westgate on to talk about his transition to Tugboat, and also speak with new CEO Seth Brown to talk about what's upcoming for Lullabot.

The Savvy Few: How to redirect a user after login in Drupal the proper way

Main Drupal Feed - Wed, 10/07/2020 - 14:07

Automatically redirecting a user after logging into your Drupal website is a common requirement. In Drupal 7, you would probably have used hook_user_login() to perform this task, but with Drupal 8 came a more robust way to handle this. Our…

Read more

Drupal Core News: Drupal 9.1.0-alpha1 will be released the week of October 19th

Main Drupal Feed - Tue, 10/06/2020 - 20:26

Reposted from the Core group on groups.drupal.org

In preparation for the minor release, Drupal 9.1.x will enter the alpha phase the week of October 19th, 2020. Core developers should plan to complete changes that are only allowed in minor releases prior to the alpha release. The 9.1.0-alpha1 deadline for most core patches is October 16. (More information on alpha and beta releases.)

  • Developers and site owners can begin testing the alpha after its release.

  • The 9.2.x branch of core will be created, and future feature and API additions will be targeted against that branch instead of 9.1.x. All outstanding issues filed against 9.1.x will be automatically migrated to 9.2.x.

  • Once 9.2.x is branched, alpha experimental modules will be removed from the 9.1.x codebase (so their development will continue in 9.2.x only). The Config Environment module is an alpha stability module in 9.1.x.

  • All issues filed against 9.0.x will then be migrated to 9.1.x, and subsequent bug reports should be targeted against the 9.1.x branch.

  • During the alpha phase, core issues will be committed according to the following policy:

    1. Most issues that are allowed for patch releases will be committed to 9.1.x and 9.2.x.
    2. Most issues that are only allowed in minor releases will be committed to 9.2.x only. A few strategic issues may be backported to 9.1.x, but only at committer discretion after the issue is fixed in 9.2.x (so leave them set to 9.2.x unless you are a committer), and only up until the beta deadline.
Drupal 8.9.0-beta1 will be released the week of November 2nd

Roughly two weeks after the alpha release, the first beta release will be created. All the restrictions of the alpha release apply to beta releases as well. The release of the first beta is a firm deadline for all feature and API additions. Even if an issue is pending in the Reviewed & Tested by the Community (RTBC) queue when the commit freeze for the beta begins, it will be committed to the next minor release only.

The release candidate phase will begin the week of November 16th. See the summarized key dates in the release cycle, allowed changes during the Drupal 8 and Drupal 9 release cycles, and Drupal 8 and 9 backwards compatibility and internal API policy for more information.

The scheduled release date of Drupal 9.1.0 is December 2nd, 2020.

Bugfix and security support of Drupal 9.0.x, 8.8.x and 8.9.x.

Security coverage for Drupal 8 and 9 is generally provided for the previous minor release as well as the newest minor release. However, Drupal 8.9.x is a Long-Term Support release where support is provided until November 2021. Based on these the following changes are upcoming:

Drupal 8.8.x Security releases will be provided until December 2nd, 2020. Drupal 8.9.x Security releases will be provided until November 2021. Bugfix support will continue into early 2021. Drupal 9.0.x Normal bugfix support ends on December 2nd, 2020. However, security releases are provided until the release of Drupal 9.2.0 on June 2, 2021.

Drupal core announcements: Drupal 9.1.0-alpha1 will be released the week of October 19th

Main Drupal Feed - Tue, 10/06/2020 - 19:15

In preparation for the minor release, Drupal 9.1.x will enter the alpha phase the week of October 19th, 2020. Core developers should plan to complete changes that are only allowed in minor releases prior to the alpha release. The 9.1.0-alpha1 deadline for most core patches is October 16. (More information on alpha and beta releases.)

  • Developers and site owners can begin testing the alpha after its release.

  • The 9.2.x branch of core will be created, and future feature and API additions will be targeted against that branch instead of 9.1.x. All outstanding issues filed against 9.1.x will be automatically migrated to 9.2.x.

  • Once 9.2.x is branched, alpha experimental modules will be removed from the 9.1.x codebase (so their development will continue in 9.2.x only). The Config Environment module is an alpha stability module in 9.1.x.

  • All issues filed against 9.0.x will then be migrated to 9.1.x, and subsequent bug reports should be targeted against the 9.1.x branch.

  • During the alpha phase, core issues will be committed according to the following policy:

    1. Most issues that are allowed for patch releases will be committed to 9.1.x and 9.2.x.
    2. Most issues that are only allowed in minor releases will be committed to 9.2.x only. A few strategic issues may be backported to 9.1.x, but only at committer discretion after the issue is fixed in 9.2.x (so leave them set to 9.2.x unless you are a committer), and only up until the beta deadline.
Drupal 8.9.0-beta1 will be released the week of November 2nd

Roughly two weeks after the alpha release, the first beta release will be created. All the restrictions of the alpha release apply to beta releases as well. The release of the first beta is a firm deadline for all feature and API additions. Even if an issue is pending in the Reviewed & Tested by the Community (RTBC) queue when the commit freeze for the beta begins, it will be committed to the next minor release only.

The release candidate phase will begin the week of November 16th. See the summarized key dates in the release cycle, allowed changes during the Drupal 8 and Drupal 9 release cycles, and Drupal 8 and 9 backwards compatibility and internal API policy for more information.

The scheduled release date of Drupal 9.1.0 is December 2nd, 2020.

Bugfix and security support of Drupal 9.0.x, 8.8.x and 8.9.x.

Security coverage for Drupal 8 and 9 is generally provided for the previous minor release as well as the newest minor release. However, Drupal 8.9.x is a Long-Term Support release where support is provided until November 2021. Based on these the following changes are upcoming:

Drupal 8.8.x Security releases will be provided until December 2nd, 2020. Drupal 8.9.x Security releases will be provided until November 2021. Bugfix support will continue into early 2021. Drupal 9.0.x Normal bugfix support ends on December 2nd, 2020. However, security releases are provided until the release of Drupal 9.2.0 on June 2, 2021.

Drupal core announcements: Drupal 9.1.0-alpha1 will be released the week of October 19th

Main Drupal Feed - Tue, 10/06/2020 - 19:15

In preparation for the minor release, Drupal 9.1.x will enter the alpha phase the week of October 19th, 2020. Core developers should plan to complete changes that are only allowed in minor releases prior to the alpha release. The 9.1.0-alpha1 deadline for most core patches is October 16. (More information on alpha and beta releases.)

  • Developers and site owners can begin testing the alpha after its release.

  • The 9.2.x branch of core will be created, and future feature and API additions will be targeted against that branch instead of 9.1.x. All outstanding issues filed against 9.1.x will be automatically migrated to 9.2.x.

  • Once 9.2.x is branched, alpha experimental modules will be removed from the 9.1.x codebase (so their development will continue in 9.2.x only). The Config Environment module is an alpha stability module in 9.1.x.

  • All issues filed against 9.0.x will then be migrated to 9.1.x, and subsequent bug reports should be targeted against the 9.1.x branch.

  • During the alpha phase, core issues will be committed according to the following policy:

    1. Most issues that are allowed for patch releases will be committed to 9.1.x and 9.2.x.
    2. Most issues that are only allowed in minor releases will be committed to 9.2.x only. A few strategic issues may be backported to 9.1.x, but only at committer discretion after the issue is fixed in 9.2.x (so leave them set to 9.2.x unless you are a committer), and only up until the beta deadline.
Drupal 8.9.0-beta1 will be released the week of November 2nd

Roughly two weeks after the alpha release, the first beta release will be created. All the restrictions of the alpha release apply to beta releases as well. The release of the first beta is a firm deadline for all feature and API additions. Even if an issue is pending in the Reviewed & Tested by the Community (RTBC) queue when the commit freeze for the beta begins, it will be committed to the next minor release only.

The release candidate phase will begin the week of November 16th. See the summarized key dates in the release cycle, allowed changes during the Drupal 8 and Drupal 9 release cycles, and Drupal 8 and 9 backwards compatibility and internal API policy for more information.

The scheduled release date of Drupal 9.1.0 is December 2nd, 2020.

Bugfix and security support of Drupal 9.0.x, 8.8.x and 8.9.x.

Security coverage for Drupal 8 and 9 is generally provided for the previous minor release as well as the newest minor release. However, Drupal 8.9.x is a Long-Term Support release where support is provided until November 2021. Based on these the following changes are upcoming:

Drupal 8.8.x Security releases will be provided until December 2nd, 2020. Drupal 8.9.x Security releases will be provided until November 2021. Bugfix support will continue into early 2021. Drupal 9.0.x Normal bugfix support ends on December 2nd, 2020. However, security releases are provided until the release of Drupal 9.2.0 on June 2, 2021.

Pages