Mar 17 2020
Mar 17

I heard a lot of good things about Midwest Drupal Camp (MidCamp) throughout the years. I also had the chance to follow Avi Schwab sharing best practices from it at various events. It is one of the real model events. I never had a chance to attend unfortunately.

In 2020, due to the ongoing pandemic, they did not have the opportunity to run the camp as usual. While that is sad, they decided to turn it around entirely and made MidCamp all digital and free to attend. This means you and I can attend finally and not just admire the event from afar! Let's do that! There is no registration or tickets required anymore, so sign up for details via email, or keep up on the site.

MidCamp - No ticket or registration required

Great Drupal 9 content

While there are lots of great sessions to participate in, I am really excited about the Drupal 9 content. Presentations will be streamed over Zoom with links being provided later in the week.

Let's get contributing

Following sessions on Thursday and Friday, there will be a virtual contribution day on Saturday from 3pm to 9pm UTC. I am really excited about these three contribution topics and would love to see you join in them! I will swap a workday out this week with Saturday to participate in this event and still have personal time for my family while they all stay at home due to the pandemic.

Olivero theme screenshot

  • Working on automation rules to fix deprecation issues in Drupal 8 projects. This is the practical application of Dan Montgomery's session. Dan and Ofer Shaal will be available and lead this topic. Rector saves a lot of manual work by automating code upgrades from Drupal 8 to Drupal 9. The immediate goal is to create Rector rules for the 15 most popular deprecations. Those 15 rules will cover 50% of all Drupal deprecations so a lot less manual work would be needed!
  • Work on contributed project Drupal 9 compatibility. Applying the above tooling combined with manual work to make contributed projects compatible with Drupal 9. Mike Lutz will be leading this topic. I would also love to help anyone interested. I maintain the overview of contributed project readiness on dev.acquia.com (thanks for the source data to the Drupal Association), which can be used to find what to work on effectively.
  • Improve the proposed new Drupal 9 default frontend theme Olivero. Various members of the team will be available to work on outstanding issues for the proposed new Olivero frontend theme. Putra Bonaccorsi, Aubrey Sambor and Brian Perry indicated they would be there.

Contribution will be coordinated on Slack I believe, more information to come later this week. Sign up for details via email, or keep up on the site. See you (virtually) there!

Mar 16 2020
Mar 16

Ten months ago I created the first version of "State of Drupal 9" and published it as an open source slideshow for anyone to review and present. It has been presented by myself and various other people since then. I kept it up to date and I got lots of feedback to improve it. Since we are closing in on the Drupal 9.0.0-beta1 release where milestone dates are better defined and the release itself is quite close, I decided to rework the whole slideshow with a more practical approach in mind focusing first on what happens to Drupal 7 and outlining the concrete practical upgrade paths for what people should do coming from Drupal 8.

I was slated to present this new version of it at DrupalCamp London, DevDays Ghent and DrupalCon Minneapolis (with Amber Himes Matz). Due to the ongoing pandemic I did not attend DrupalCamp London anymore and further events are being gradually cancelled or postponed. So I don't know if I or someone else will have a chance to present this in person anytime soon. (Which I think is for the better of our health). However, you can still review the content yourself and present it virtually on a remote Drupal meetup or conference or at your virtual company meeting. I did present the slides for DrupalCamp London remotely myself and the camp made the recording kindly available:

I added plenty of speaker notes. You can present/review it from https://slides.com/gaborhojtsy/state-of-drupal9 or fork it (even with a free slides.com registration) and replace the "About me" slide as well as the opening and closing thanks slide with your attribution. Please keep the rest of the attribution intact. Instructions are in the slides.

I'll keep this version updated from now on and archived the old version with a note pointing to this.

Jan 17 2020
Jan 17

As Dries Buytaert explained in his Plan for Drupal 9 post at the end of 2018 (emphasis mine):

Drupal 8's biggest dependency is Symfony 3, which has an end-of-life date in November 2021. This means that after November 2021, security bugs in Symfony 3 will not get fixed. Therefore, we have to end-of-life Drupal 8 no later than November 2021. Or put differently, by November 2021, everyone should be on Drupal 9.

Working backwards from November 2021, we'd like to give site owners at least one year to upgrade from Drupal 8 to Drupal 9. While we could release Drupal 9 in December 2020, we decided it was better to try to release Drupal 9 on June 3, 2020. This gives site owners 18 months to upgrade. Plus, it also gives the Drupal core contributors an extra buffer in case we can't finish Drupal 9 in time for a summer release.

Here we are 14 months later and while most people took the June 3 release date and took it for granted, it is still not guaranteed! However you can help in various ways to make it much more likely!

Late last fall, we focused on defining what it means if we cannot make the June 3, 2020 release despite our best efforts and what is an early indicator that tells us we are going to miss it. First of all, that meant defining requirements for the first alpha release and requirements for the first beta (API complete) release. Also we needed to set some expectations as to when do we want to see the API-complete beta release to give enough time for the ecosystem to test it and find important problems in time. Based on how soon the beta requirements are met, there are three release scenarios and the best case ending in the June 3, 2020 release date for Drupal 9 has a beta deadline in 6 weeks! Yes, 42 days!

Alpha requirements simplified

The key requirements for the first alpha release are simple. We wanted to update the key dependencies: Symfony to version 4.4 and Twig to version 2, as well as remove frontend polyfills that were not needed and remove most of jQuery UI (which were already deprecated in Drupal 8). This gets our most important dependencies up to shape to what will be in Drupal 9. We also made it possible for contributed projects to depend on Drupal 8 and 9 at the same time, so they will not need to branch for Drupal 9 support.

There are two outstanding things for the Drupal 9 alpha:

  1. Drupal.org does not yet have an automated packaging pipeline that conforms to all the recent composer related improvements and therefore making core releases is error prone. I don't believe you can help with this at this time, the Drupal Association is hard at work on this.
  2. Drupal core should use a major version agnostic update feed for projects which is already being provided by Drupal.org but the core code to consume it is still in the works. While this is actively being worked on, reviews are always helpful. This will make sure Drupal 9's Update Status gets only contributed projects that are actually Drupal 9 compatible, while contributed modules will not need to establish a Drupal 9 branch.

Beta requirements simplified

The beta requirements are a bit more complicated and longer of course because we are looking at being API complete here. Once again, for the June 3, 2020 release date, we need these done in 6 weeks! The issue lists must haves and should haves, however the should have issues should be considered must-have for the June 3, 2020 release date and would only be reconsidered later if that date cannot be met. Here is a simplified rundown of the beta requirements:

  1. We want to keep dependencies up to date. There is no concrete pressing issue here at the moment that I know, but this really depends on how our dependencies evolve.
  2. We'd like to remove all the deprecated APIs themselves. Last year I built a graph to track this, and it shows nicely that we are down to half of them remaining (yay!), but still quite enough to deal with. There are various outstanding issues you can help with here.
  3. We want to make sure people can update to Drupal 9 from Drupal 8 by resolving critical upgrade path bugs. If you cannot update to a later version of Drupal 8 due to some critical bug, then you will be stuck on your version of Drupal 8. Not good. These include views, layout_discovery, taxonomy, menu_content, etc. related issues. All of them need help. If you are on an older version and can reproduce the problems, that is useful. If you have experience in these areas, your input would be useful.
  4. It will only be possible to update to Drupal 9 from Drupal 8.8 or 8.9, so all older update paths and their tests should be removed. Older versions of Drupal 8 will themselves be unsupported already at the time of Drupal 9's release. This issue is getting close but needs reviews.
  5. No new security or data integrity issues should be in Drupal 9. If there are any, they should be resolved. I don't know of any issues at the moment here.
  6. The API should be complete. There are no critical API additions or changes that I know of at the moment in this general category.
  7. We want to make sure people can migrate from Drupal 6/7 to Drupal 9. This needs the remaining multilingual migration paths to go stable. This is an area where we posted several call to actions, but still need your help. There are proposed migration paths for node translations and entity translations that respect revisions but they need at least code reviews to make sure they are good. Otherwise if you had content translations with revisions, the migration will not be correct. Without that, multilingual migrations will not go stable.
  8. PHP requirements should be finalised. It is likely at this time that Drupal 9 will require PHP 7.3 that is being worked on currently and could use a review.
  9. Database requirements should be finalised in terms of MySQL/MariaDB/Percona and PostgreSQL. Both issues need data as to which distributions and hosts support certain versions.
  10. The right security update information should be provided for users taking the one year support cycle and long term support of the last Drupal 8 release. This could also use reviews.
  11. We should put Drupal's base theme on a track so that it can evolve in Drupal 9 finally. This involves creating a new stable9 theme and decoupling the core themes from Classy. Various issues to help with here.
  12. Drupal.org should support multi-core compatibility eg. on project pages, localize.drupal.org, etc. This work is currently deprioritised by the Drupal Association due to the focus on the packaging pipeline blocker that I listed first. Once this gets attention, it will likely uncover core issues to resolve as well.

The two areas that receive the least attention at the moment are upgrade path blockers and the stability of the multilingual migration path, so those two are the most pressing where we need your help!

While the above is a complete rundown of the current beta requirements, it may change later on, so refer to the beta requirements issue later on for up to date information.

What happens if all the above are not done by end of February (in six weeks)

If all goes well, with your help, we'll be done with all the above in six weeks. If that does not work out, we have a plan B and a plan C. Here is how those options unfold. If beta requirements are only done two months later by end of April, then Drupal 9's first beta will be released on the first week of May and Drupal 9 is to be released on August 5, 2020. If the beta requirements are only done by end of August (four more months later), than the first beta will be released than with a Drupal 9 release date of December 2, 2020. In this case a Drupal 8.10 may also be released if needed. These dates are spelled out well in the Drupal core release cycle overview. I created this visual to help understand the alternate timelines:

Drupal 9 release scenarios visualised

While I think it is reassuring that we have plans for what happens if our initial date targets don't work out, unfortunately the end of life date at the end of next year for Drupal 8 is not movable because it is based off of Symfony 3's end of life. So the sooner we can make Drupal 9 happen (while meeting the upgrade and stability requirements) the better. What are you going to work on to help?

Helping with contributed projects

Based on the PHP deprecations our tools can identify, 43% of contributed projects would only need info.yml file updates to be Drupal 9 compatible. An additional 41% of the remaining projects have only issues that are resolvable now (even while keeping support for Drupal 8.7). Solving those anytime between now and Drupal 9's release (whenever it is) would put us to almost six thousand contributed projects compatible with Drupal 9 on day one! While that is a very idealistic number, helping with contributed projects is nonetheless a great avenue to contribute to Drupal 9 readiness. Help at the Drupal Global Contribution Weekend at end of next week or anytime before and after! I prepared a quickstart guide for this occasion.

Jan 15 2020
Jan 15

This year Drupal Global Contribution Weekend is on January 24-26, 2020 with such varied locations as Delhi, Novosibirsk, Ghent, Frankfurt, Milan, Zurich, Lutsk, London (on two continents!), Boston, Minneapolis, etc. Wow! It is truly a global gathering! With Drupal 9 planned to be released later this year, what better to focus on, than making drupal.org projects Drupal 9 ready?

To help you do that I went in and updated my open source State of Drupal 9 talk. People can use this to present at any location to get people up to speed about Drupal 9. If you need a video recording of it, there is one from DrupalCamp Belarus in May 2019. While the content got slightly updated since then, the recording should help get it.

After or instead of presenting that session, I thought a quickstart guide would be really useful to help people get started with contributing. While this looks like a colorful guide you would print, it is actually full of useful links (some to my earlier blog posts for details), so I suggest you use it in digital form.

What are you planning to do for Drupal Global Contribution Weekend this year?

Jan 09 2020
Jan 09

We started the "All things Drupal 9" meetings all the way back in October 2018 to start preparing for the new major release. Now in 2020, the year of Drupal 9, it was natural to make the meeting happen every Monday given the target dates coming up fast.

Contributed project maintainers, site owners, core developers are all welcome. If you are planning a Drupal 9 project for later in the year, this is your place as well. We open the floor with equal opportunity for people to propose topics, so we can cover your pressing questions as well! Join at 7pm UTC in the #d9readiness channel on Drupal Slack any Monday. The next meeting will be on January 13th, 2020.

We've been promoting Drupal 9's June 3rd 2020 target release date a lot, but that can only happen if the Drupal 9.0.0 beta requirements are all done by the end of February 2020, which is coming up real fast. There are still a lot to do and we need your help! If that does not happen, then the release will happen in August or December. While that would give less time for Drupal 8 users to update, we cannot compromise on the stability of Drupal 9 out of the gate.

The three Drupal 9 release scenarios

Check out the detailed alternate timelines at https://www.drupal.org/core/release-cycle-overview

Jan 09 2020
Jan 09

We started the "All things Drupal 9" meetings all the way back in October 2018 to start preparing for the new major release. Now in 2020, the year of Drupal 9, it was natural to make the meeting happen every Monday given the target dates coming up fast.

Contributed project maintainers, site owners, core developers are all welcome. If you are planning a Drupal 9 project for later in the year, this is your place as well. We open the floor with equal opportunity for people to propose topics, so we can cover your pressing questions as well! Join at 7pm UTC in the #d9readiness channel on Drupal Slack any Monday. The next meeting will be on January 13th, 2020.

We've been promoting Drupal 9's June 3rd 2020 target release date a lot, but that can only happen if the Drupal 9.0.0 beta requirements are all done by the end of February 2020, which is coming up real fast. There are still a lot to do and we need your help! If that does not happen, then the release will happen in August or December. While that would give less time for Drupal 8 users to update, we cannot compromise on the stability of Drupal 9 out of the gate.

The three Drupal 9 release scenarios

Check out the detailed alternate timelines at https://www.drupal.org/core/release-cycle-overview

Dec 04 2019
Dec 04

What’s new in Drupal 8.8.0?

The last normal feature release of Drupal 8 includes a stable Media Library as well as several improvements to workspaces and migrations. The new experimental Claro administration theme brings a fresh look to site management. This is also the first release to come with native Composer support.

Download Drupal 8.8.0

Stable Media Library

The Media Library module allows easy reuse of images, documents, videos, and other assets across the site. It is integrated into content forms and seamlessly fits into CKEditor. You can upload media right from the library and even reuse a combination of uploaded and existing media. Media Library was previously included with Drupal core as a beta experimental module.

New experimental administration theme

The Claro administration theme was added to Drupal core with beta experimental stability. The new theme is clean, accessible, and powerful. Administration pages are more touch-friendly, and color combinations and contrasts are more accessible.

Significant improvements to Workspaces

It is now possible to define hierarchical workspaces (such as preparing a "New Year's" issue for a magazine under the "winter issue", while both receive changes to be deployed). Workspaces can now work with Content Moderation, and path alias changes can also be staged.

Native Composer support included

Drupal 8.8.0 is the first release to include native Composer support without reliance on third-party projects to set up Drupal with its dependencies. New sites can be created using a one-line command.

Migration improvements

The multilingual migration path is still experimental, but has received various updates. This includes handling of vocabulary language settings, term language information, and localization. Modules can now specify whether migrations provided by them are finished or not finished to help audit completeness of available migrations.

New experimental Help Topics module

The existing help system is module based, whereas users intend to complete tasks, not use modules. A new task-based Help Topics beta experimental module has been added to bring in-Drupal help to the next level.

The way to Drupal 9

Drupal 8.8 is the last minor release of Drupal 8 to include significant new features or deprecations prior to 9.0.0. The next (and final) minor release, 8.9, is planned to be a long-term support release that will include all the same changes as Drupal 9.0. It will not contain significant new features compared to 8.8.0, although existing experimental modules may become stable, and small API and UX improvements can still be added.

Drupal 8.9.0's planned release date is June 3, 2020, and our target release date for Drupal 9.0.0 is the same day. Most Drupal 9 preparation steps can be done on your Drupal 8 site, custom code and contributed modules now.

What does this mean for me?

Drupal 8 site owners

Update to 8.8.0 to continue receiving bug fixes and prepare for 9.0.0 (or 8.9.0). The next bug-fix release (8.8.1) is scheduled for January 8, 2020. (See the release schedule overview for more information.) As of this release, sites on Drupal 8.6 will no longer receive security coverage. (Drupal 8.7 will continue receiving security fixes until June 3, 2020.)

Note that all Drupal 8.8.0 sites (new installs and updates) now require at least PHP 7.0.8.

Updating your site from 8.7.10 to 8.8.0 with update.php is exactly the same as updating from 8.7.8 to 8.7.9. Drupal 8.8.0 also has updates to several dependencies. Modules, themes, and translations may need updates for these and other changes in this minor release, so test the update carefully before updating your production site. Read the 8.8.0 release notes for a full list of changes that may affect your site.

Drupal 7 site owners

Drupal 7 is fully supported by the community until November 2021, and will continue to receive bug and security fixes throughout this time. From November 2021 until at least November 2024, the Drupal 7 Vendor Extended Support program will be offered by vendors.

The migration path for monolingual Drupal 7 sites is stable, as is the built-in migrationuser interface. For multilingual sites, most outstanding issues have been resolved. Please keep testing and reporting any issues you may find.

Translation, module, and theme contributors

Minor releases like Drupal 8.8.0 include backwards-compatible API additions for developers as well as new features.

Since minor releases are backwards-compatible, modules, themes, and translations that supported Drupal 8.7.x and earlier will be compatible with 8.8.x as well. However, the new version does include some changes to strings, user interfaces, internal APIs and API deprecations. This means that some small updates may be required for your translations, modules, and themes. Read the 8.8.0 release notes for a full list of changes that may affect your modules and themes.

This release has advanced the Drupal project significantly and represents the efforts of hundreds of volunteers and contributors from various organizations, as well as testers from the Minor release beta testing program. Thank you to everyone who contributed to Drupal 8.8.0!

Nov 20 2019
Nov 20

Gábor Hojtsy

An avid open source enthusiast and contributor. I am a Drupal 8 core product manager and initiative coordinator coordinator working with and on the open source project itself at Acquia. I am a regular Drupal event speaker and organizer, do communication and social media for various initiatives.

I used to be the Drupal 8 multilingual initiative lead and localize.drupal.org initiator. Also I am the former release manager of Drupal 6.

You can also find me passionate about singing, music and amateur acting, especially when these are all combined, however I have little time for that alongside my two adorable kids.

Head to the contact page to send a mail.

Nov 18 2019
Nov 18

In his State of Drupal keynote at DrupalCon Amsterdam, Dries Buytaert showed once again some tools to use to prepare for Drupal 9 including the Upgrade Status module. To me the process is even more interesting than the tools, because it is entirely different from the last upgrade. As I wrote last week, you now make a lot of incremental improvements on your existing Drupal 8 site that makes the gap to Drupal 9 significantly smaller.

It is a new mindset to look at your Drupal 8 site to improve in preparation for Drupal 9 and we have tools to identify those improvements to make. However Dries also mentioned that we are not quite there to automate those improvements. Back in May Dezső Biczó of Pronovix built out a proof of concept integration with Rector that implements a sample set of refactors, including changes for global constants and best effort solutions to some EntityManager uses, a UrlGeneratorTrait and a drupal_set_message() rector. While the extent of impact of the global constant rectors are not yet known due to limitations in our tools not finding them yet, the rest of the implemented rectors are definitely tapping into the top list of deprecated APIs.

Unfortunately slightly after he posted his blog post about the proof of concept, Dezső did not have time for this project anymore. I think this tool could be of huge help in removing deprecated API use in your projects and thus making them more modern Drupal 8 projects (while being more if not already entirely compatible with Drupal 9). However, we need contributors to cover more of the deprecated APIs, especially around file_*() and db_*() functions. If we can figure out rectors for most of the top 15 errors (and Dezső already did some of them), we could cover over half of all deprecated API use in contributed projects:

Donut chart of top 15 usages of deprecated APIs on drupal.org

To top that off, I also think a simplytest.me style online service would be very useful to run drupal8-rector on your drupal.org project and suggest a patch to apply to remove deprecated APIs. Even better if it allows custom code to be uploaded so people can use it for that too. The more we can automate these tasks the easier the transition of Drupal 8 to 9 will be.

Submit issues and pull requests in the drupal8-rector project to improve API coverage. Look for me on Drupal slack if you get stuck and I'll try to help. I'd also love to talk to you if you want to set up an automated service. Let's do this!

Nov 11 2019
Nov 11

I've had various deep discussions with contributed module maintainers recently about their process to update code to Drupal 9 and one point struck me. We are so attached to "Make it ready for Drupal 9" that a key point of the message may be lost. Check out this section of the State of Drupal keynote from DrupalCon Amsterdam 2019 where Dries Buytaert showcases Johanna's relatively simple site that she prepares for the Drupal 9 upgrade entirely in Drupal 8. Notice that she does all the steps in Drupal 8 other than the final Drupal 9 upgrade itself:

This is the base principle of the process towards Drupal 9, making your Drupal 8 site better and more prepared, so the move to Drupal 9 itself at the end is a relatively small step and you got a better Drupal 8 site in the meantime. You are not jumping over the fence all at once, but in gradual steps. I thought a comparison with Drupal 6 to 7, 7 to 8 and 8 to 9 would help, since people may have assumptions or prior experiences with those, so its worth looking at how our new process compares to the two previous transitions.

Update process with Drupal 6 to 7, 7 to 8 and 8 to 9, as explained in the text too.

Concentrating on the high level steps to do, this is how the three processes compare:

  1. From Drupal 6 to 7, there was a long list of changes, but the general API of Drupal stayed mostly the same. You would need to update some things in your custom code. Even though it may be a few things, your new code would only work with the new major core version. When you went to update from Drupal 6 to 7, you needed to keep your database in the background, use all the new Drupal 7 compatible code, and run update.php to carry over your database.
  2. From Drupal 7 to 8, the whole API paradigm of Drupal changed, so you needed a heavy rewrite of your custom code. There was absolutely no way custom Drupal 7 code would work with Drupal 8. The database also changed a lot, so instead of running an update.php script that would update your core and contributed database data, you would do a big database migration.
  3. The Drupal 8 to 9 process is entirely different again, but in a good way. First of all we are back at you running update.php on your codebase (no data migration!). So we went back to what we already knew worked well earlier. But the code updates also got quite different. This time, we are introducing deprecated APIs in minor Drupal 8 releases and add the new APIs to use instead. So we are gradually making Drupal 9 available in Drupal 8 as much as possible within our own control.

The benefits are huge! This means that custom code and drupal.org projects can be gradually updated within Drupal 8 on the way Drupal 9 step by step. Making improvements on the Drupal 8 site by updating contributed modules and adopting the new APIs in custom code like Johanna did in Dries' demo is making the Drupal 8 site itself better and closing the gap to Drupal 9 at the same time. All the new APIs get more use and thus get more battle tested in the process, all before Drupal 9 is even released. So all there will be left for Drupal 9.0.0 itself is to remove the old APIs and update third party dependencies.

Enough of the marketing, let's talk about the fine print where some contributed modules may not be kept Drupal 8 compatible and become Drupal 9 compatible at the same time.

The 12% size wrench in the system

As I posted in July, 76% of deprecated API use was possible to fix already at the time. I kind of brushed off the "Fixable later" category because it was not yet a pressing need then. But let's look at how we arrive at what can be fixed now vs. later.

In 2018 we extended security coverage of Drupal core minor versions to 12 months. That means that there is a 6 month overlap of when a new minor release comes out but we are still supporting the two versions prior. For example, when Drupal 8.8.0 comes out on December 4, 2019, we'll stop supporting Drupal 8.6.x and still keep supporting Drupal 8.7.x until June 3, 2020, the date of our next minor release.

For custom code written on a site, as Drupal core is updated, the custom code can keep up to date with the latest and greatest APIs. However for contributed modules, the choice is up to the module maintainer. There is no point in supporting core versions which are out of security coverage. But if maintainers keep updating to the latest core minor APIs, their contributed module's latest versions would not be compatible with sites running perfectly supported core versions. This becomes a problem especially if the contributed module in question needs to make a security release, when it needs to create a new branch retroactively for an old core version unless they want to force users of Drupal core to update their security-supported versions.

Deprecated API use breakdown on October 22, 2019 as explained in the text.

So this is where the "Fix now" vs. "Fixable later" differentiation comes in. Here is more fine-grained breakdown of the up to date data from October 22. Still 75% is fixable now. Breaking down the "Fixable later" category, another 6% is fixable once Drupal 8.6.x goes unsupported on December 4, 2019. A good 8% cannot be automatically categorized unfortunately. That leaves 12% that are deprecations introduced in Drupal 8.8. This includes some that have replacements in prior Drupal versions, so the data could use some cleaning up. But nonetheless there will be a measurable amount of deprecated APIs that one cannot fix right now and still be compatible with Drupal 8's all supported branches and Drupal 9.0.0 on day one.

Some contributed project maintainers feel the campaign to update for Drupal 9 makes them look bad, because this appears to be a catch 22 situation that puts them in a difficult corner.

What can you do in this case?

Since you are serious about supporting Drupal 8's supported branches (huge thanks for that!), there are the following options:

  1. Add temporary workarounds to the deprecated APIs, such as conditional code to only use the deprecated APIs when they are still there. Mike Lutz and Sascha Grossenbacher (Berdir) worked a lot in this area and I believe they are both working on posts with tips. (Will link them in when available.)
  2. Create a new major branch of your project for Drupal 8.9.0/9.0.0 support specifically. Or if you are also affected by some dependency update, such as Symfony 4.4 API changes, branch for Drupal 9.0.0+ support in particular and keep your existing branch for Drupal 8 / Symfony 3.4. One thing to note here is Drupal.org does not allow for 9.x releases anymore, so even after you created a 9.x branch, you will not be able to make releases out of it. This is in preparation for the introduction of semantic versioning for contributed projects, which will do away with the 8.x/9.x prefixes entirely. The workaround in the meantime is to create a new 8.x branch and use the right core_version_requirement value.
  3. Assume for the best case scenario, and drop support for Drupal 8.7 earlier. If you need to release a critical bug fix or a security release, you can still branch two new minor versions of your project, one from the prior minor version that was still 8.7 compatible and one from the new code that is not. Include the fixes in both. Add composer and info.yml dependency information to make it impossible to install the incompatible versions on 8.7.x. (Hat tip to Sascha Grossenbacher (Berdir) for this idea).

It may not be possible to attain 100% Drupal 9 compatibility in each contributed module on day one of the Drupal 9.0.0 release, and there will be some where the update is not that simple. I firmly believe our process is still way better then what we had before, and we are learning a lot from the mistakes we make. That said, I'll keep advocating to prepare now because 75% of the work can be done anytime. Assuming the percentages stay the same, this raises to 81% very soon in early December (and may be even higher based on some of the uncategorized items falling into this field). That is a lot of preparation that we can do already! If instead of asking is this entirely Drupal 9 compatible, we switch our minds to gradually improve within Drupal 8 and get much closer to Drupal 9, then we can use our time quite flexibly and make the existing Drupal 8 sites better. Only a relatively small gap remains at the end then, which was the goal to begin with.

Further reading

  1. If you use Upgrade Status, it includes the same categorization and can be used to focus on what is actionable now.
  2. I also covered this topic in my open source State of Drupal 9 slides that you can present at your own meetup, company, conference, etc.
  3. The official Drupal 9 documentation also suggests keeping supported core branches in mind.
Oct 16 2019
Oct 16

Join the team making Drupal 9 as part of the contribution events in person at DrupalCon Amsterdam and remotely! We'll be spending the last day of DrupalCon Amsterdam working on three things.

  1. Removing deprecated API use from Drupal 8 contributed projects to get them ready for Drupal 9.
  2. Updating core dependencies and removing deprecated APIs from Drupal 9 itself.
  3. Improve the tools and documentation that help people prepare for Drupal 9.

On October 31st, join on Slack even if you are there in person but definitely if you are remote. We'll meet in the #d9readiness channel on Drupal Slack. If you’re at Drupalcon Amsterdam, come to Europe 2 Forum!

To remove deprecated API use from contributed projects:

  1. Tools: Pull up the getting started info at https://tiny.cc/d9readiness and get set up with the drupal-check tool to check your code for deprecated API use.
  2. Help people who want to learn how to remove deprecated API use from projects, or remove some deprecated API use yourself! In minutes, you too could help make Drupal 9! Here are tips and tricks for the most common deprecated APIs: https://github.com/mglaman/drupal-check/wiki/Deprecation-Error-Solutions.
  3. Pick an issue: Check the list of issues tagged Drupal 9 compatibility + Amsterdam2019 (or use your own module!).
  4. If you're a module developer who would like to get a better chance to having your module reviewed / patched by a new contributor there, please create (or tag an existing) issue with the Drupal 9 compatibility + Amsterdam2019 tags!

To remove the deprecated APIs themselves, update dependencies in Drupal 9 or improve the deprecated API checking tools and documentation, please ask for specifics in the Slack channel or in person. The Drupal 9 tables will be easy to find!

You can also help spread the word by retweeting this:

Join #IMadeDrupal9 at @DrupalConEur and remotely!https://t.co/85IUEelGqK pic.twitter.com/uKWDx16Nid

— Gábor Hojtsy (@gaborhojtsy) October 16, 2019

1xINTERNET will even supply a limited amount of stickers to proudly present that you made a difference!

Thanks everyone for contributing to making Drupal 9!

Sep 02 2019
Sep 02

Drupal 8.7.7 expected later this week is the first Drupal release to support extensions compatible with multiple major versions of Drupal. This is huge!

Drupal 9 is planned for June 3, 2020 and we are aiming to make the transition as smooth as possible. In fact we build Drupal 9 in Drupal 8 with API deprecations and optional support for new dependencies (Symfony 4.4 is getting very close, while Drupal 8.7.0 was already Twig 2 compatible). Extensions following these deprecations and making sure they are compatible with the updated dependencies could have codebases that are both compatible with Drupal 8 and 9 at the same time, meaning less support burden and earlier Drupal 9 compatibility. In March 48% of contributed projects on Drupal.org were already "Drupal 9 compatible" (as we could detect at the time), and that increased 54% by July (highfive!). These projects will now have one more thing to do, a one line info.yml file addition, to allow their existing codebase to also run on Drupal 9.

✋Drupal contrib maintainers, thank you! You are already contributing a lot to a successful Drupal 9. Projects that are "compatible with Drupal 9" (as much as we know now) are up to 54% from 48% since March. Deprecated API use is decreasing overall.

You are awesome, keep it up! pic.twitter.com/mHpw4ET0P4

— Gábor Hojtsy (@gaborhojtsy) August 2, 2019

The core: 8.x key did not cut it anymore

Drupal 8 looks at extension .info.yml files and checks for the core: 8.x key to check if the extension can be used with Drupal 8. Unfortunately this was not adequate already due to API additions in Drupal 8 minor releases. You could not specify an extension was only compatible with Drupal 8.4+. People devised clever tricks with dependency on certain versions of the system module, but that was still limiting due to inability to depend on specific patch releases. In case your extension depended on a bugfix being present, you cannot set a dependency on Drupal 8.4.1+ in any way.

Introducing the core_version_requirement key

While solving this issue it became apparent that solving it with the existing core: 8.x key is going to cause backwards compatibility problems with existing Drupal 8 sites. The format of the value could not be changed without causing issues, so a new core_version_requirement key was introduced. This now allows to depend on major and minor versions of core as well as specify multiple version requirements even between multiple minor Drupal versions. For example if you would need a bugfix that is to be included in both Drupal 8.7.23 and 8.8.3 (imaginary future versions) but you wouldn't care for the minor version, then you would use the following, making your module incompatible with versions before the particular bugfix you need on both minor branches, as well as incompatible with all older Drupal 8 branches:

name: My Module
type: module
core_version_requirement: ~8.7.23 || ~8.8.3

Such precision was never possible before!

The new feature is made available in 8.7.7 to help prepare for Drupal 9, as this makes it possible to also declare Drupal 9 compatibility with the existing codebase you already have. Drupal 8.7.x will get security support up until the planned release of Drupal 9 on June 3, 2020. For extensions that only support Drupal 8.7.7 and later you can now exclusively use the core_version_requirement key. If the extension is also Drupal 9 compatible:

name: My Module
type: module
core_version_requirement: ^8.7.7 || ^9

For extensions that also support older versions, you should keep the core: key as well. The core_version_requirement key will be ignored by older Drupal versions, and new versions will validate that you specified non-conflicting requirements in the two keys (with regards to Drupal 8 support) so for extensions supporting older core versions, core_version_requirement also needs to be permissive, but could also allow compatibility with Drupal 9 too:

name: My Module
type: module
core: 8.x
core_version_requirement: ^8 || ^9

Read more about this change in the change notice. There is also work ongoing to support dependency metadata from composer.json to drive Drupal's dependency resolution as well. That will coexist with this simpler approach and will provide a more composer-native solution for those who already adopted composer for their extensions. In the meantime at least core_version_requirement will limit what Drupal would install while composer.json requirements will limit what composer will download. Because both Composer and Drupal use the term install, but those don't mean the same thing, here is a comparison chart:

  core: 8.x system module dependency core_version_requirement composer.json dependencies Can be used from Drupal 8.0.0+ Drupal 8.0.0+ Drupal 8.7.7+ Drupal 8.0.0+ Allows minor version precision No Yes Yes Yes Allows patch version precision No No Yes Yes Allows multiple constraints No No Yes Yes Limits composer install (download) No No No Yes Limits Drupal 8 install Yes Yes Yes No, unless explicit support is added. Allows Drupal 8 and 9 install with same codebase No No Yes No, unless explicit support is added.

What happens to Drupal.org project version numbers then?

So a 8.x-1.3 version of an extension on drupal.org may only be compatible with a subset of core, but that was already the case earlier. Now an 8.x-1.3 version of an extension on drupal.org may also be compatible with Drupal 9. How will this work? Drupal's composer integration already ignores the 8.x prefix from version numbers and only cares about the project specific version. Drupal core already only installs extensions where the core compatibility requirements are met regardless of which version number was the package you used to download (8.x modules may be only compatible with 8.4+ already). So the ultimate plan is to do away with the 8.x prefix in extension numbers entirely on drupal.org and support semantic versions for contributed extensions instead. In the short term, the Drupal.org project browser also needs to be updated to take the dependency metadata and use that to power compatibility filters, instead of merely using the version number prefix.

Jul 30 2019
Jul 30

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

Stop using drupal_set_message() now!

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

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

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

Figure visualising the data explained in the text.

76% of deprecated API use can already be resolved

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

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

Work with project maintainers

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

https://t.co/hf2ENvlZSo projects can now specify Drupal 9 porting information, so *you* can direct *your* contributors to provide the most valuable help on the way to Drupal 9, fund the process or just step back (for now). Edit your project to help your contributors help you! pic.twitter.com/l1OWwOllBK

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

More to come

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

Correction: An earlier version of this post said there were 43% additional fixable deprecations for a total of 72%. Thanks to Ryan Aslett for corrections, the correct numbers are 47% and 76% respectively. Images and text fixed.

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

Jul 19 2019
Jul 19

On our way to Drupal 9 every site will need to take care of making updates to their custom code as well as updating their contributed projects. However this time, instead of needing to rewrite code, only smaller changes are needed. Most contributed modules will only need to deal with a couple changes. Collaborating with project maintainers is the best way to get to Drupal 9. The first beta of the Upgrade Status module alongside recent drupal.org changes focus on making this much easier.

Upgrade Status beta provides better insight into Drupal 9 readiness

Take the first beta of the Upgrade Status module and run it on your site. It will provide executive summaries of results about all scanned projects and lets you inspect each individually.

Custom and contributed projects are grouped and summarised separately. You should be able to do all needed changes to your custom code, while for contributed projects you should keep them up to date in your environment and work with the maintainers to get to Drupal 9. The later is facilitated by displaying available update information inline and by pulling the Drupal 9 plan information from drupal.org projects and displaying it directly on the page.

This is how the summary looks like after scanning a few projects:

Upgrade Status summary page after scanning several projects.

Digging deeper from the executive summary, you can review each error separately. The beta release now categorizes issues found to actionable (Fix now) and non-actionable (Fix later) categories with a Check manually category for items where it cannot decide based on available information. For custom projects, any deprecation is fixable that has replacements in your environment while for contributed projects supporting all core versions with security support the window is shifted by a year. Only deprecations from two or more releases earlier can be fixed (compared to the latest Drupal release) while keeping Drupal core support. So somewhat ironically, Upgrade Status itself has deprecated API uses that it cannot yet fix (alongside ones it could fix, but we have them for testing purposes specifically):

Upgrade Status project issue list categories

The module is able to catch some types of PHP fatal errors (unfortunately there are still some in projects that we need to figure out the best way to catch). The @deprecated annotation information guiding you on how to fix the issues found are also displayed thanks to lots of work by Matt Glaman.

Own a Drupal.org project? Direct contributors to help you the way you prefer!

If you own a Drupal.org project that has Drupal 8 code, you should specify your Drupal 9 plans. It is worth spending time to fill in this field to direct contributors to the best way you prefer them help you, so contributions can be a win-win for you and your users alike. Whether it is a META issue you plan to collect work or a specific time in the future you will start looking at Drupal 9 deprecations or a funding need to be able to move forward, letting the world know is important. This allows others to engage with you the way you prefer them to. Additionally to it being displayed in Upgrade Status's summary it is also displayed directly on your project page!

Go edit your project and find the Drupal 9 porting info field to fill in. Some suggestions are provided for typical scenarios:

Drupal 9 porting info field on a project

This will then be displayed on your project page alongside usage and security coverage information. For example, check it out on the Upgrade Status project page.

Thanks

Special thanks for dedicated contributors and testers of the Upgrade Status module who helped us get to beta, especially Karl Fritsche (bio.logis), Nancy Rackleff (ThinkShout), Tsegaselassie Tadesse (Axelerant), Bram Goffings (Nascom), Travis Clark (Worthington Libraries), Mats Blakstad (Globalbility), Tony Wilson (UNC Pembroke), Alex Pott (AcroMedia, Thunder), Charlie ChX Negyesi (Smartsheet), Meike Jung (hexabinær Kommunikation). Thanks to Neil Drumm (Drupal Association) and Angela Byron (Acquia) for collaboration on the Drupal 9 plan field.

Jun 24 2019
Jun 24

The planned Drupal 9 release date is June 3, 2020. While the Drupal 9 branch is not yet open, we've been working on Drupal 9 ever since the release of Drupal 8.0.0 through our deprecation processes. In fact, that is our process to clean up and refactor our APIs.

For a PHP API to be removed we need to deprecate and introduce a replacement (as appropriate). For a module to be removed, we need to deprecate it and at least move it to a contributed module (or provide a replacement in core). For a JavaScript dependency to be removed (such as the already end of life jQuery UI), we need to deprecate it and provide a replacement, and so on. So what can we get rid of in Drupal 9 finally? Well, all the things marked deprecated.

Other than third party dependency updates, things not deprecated in Drupal 8 will stay in Drupal 9 and be subject to backwards compatibility support in Drupal 9 until its end of life (likely around the end of 2023).

And this is a good thing. We want stability with Drupal, we want people to invest and find their investments work with Drupal for a reasonable time. To completely answer my clickbait title though: how long do we have to "finally" get rid of something? Well as per Dries's DrupalCon Seattle keynote, we have until Drupal 8.8 to define what we are deprecating for (and thus removing in) Drupal 9. Here is the video snippet:

What does that mean in practice? 8.8.0-alpha1 is by when we need to get the API for Drupal 8.8.0 done and therefore the API of Drupal 9 done (other than third party dependency updates). And 8.8.0-alpha1 is scheduled for the week of October 14th, 2019.

In other words, you have 111 days to get your least favourite thing removed from Drupal. If not, well, we will live with backwards compatibility to what we have in October 2019 for 4 more years to come.
Jun 07 2019
Jun 07

I created and shared an open source set of editable slides with plenty speaker notes titled "State of Drupal 9" early in May, based on my webinar with Dries and then the Drupal 9 parts of the DrupalCon Seattle Driesnote. I hope that we can bring this know-how to a lot of conferences, meetups and to companies so people are more aware of what is coming, what happens to Drupal 8 and 7, what's so great about Drupal 9 and what are the key tools involved.

Before I even presented the slideshow first, I already got improvement suggestions from people presenting it elsewhere. So the first time I got to present this session in Minsk, Belarus at the kind invitation of DrupalCamp Belarus organizers, it was already improved from when I first published it. I will keep updating the slides and present where I can in the coming months. Please, do it yourself too! Translate, shorten, lengthen, etc. to match your audience and timing needs, as long as the key messages get through. Be an important contributor to Drupal 9 this way!

Here is the recording from DrupalCamp Belarus:

May 24 2019
May 24

Dwayne McDaniel did some thorough reporting of deprecated code use in all Drupal 8 contributed modules in March. Ultimately this kind of reporting would be best to have on drupal.org but while that is figured out, Dwayne's data set provides a very nice way to mine data about Drupal 9 readiness of contributed modules and to inform our tooling to improve the process. His original numbers showed that almost 44% of contributed modules had no deprecated code use at the time. What I was interested in was how to help the rest of the 56%.

Dwayne created an updated process and a new repository this week with fresh data. I was still curious so I delved right into the data and started mining it. A key question I was interested in is how much of the most widespread deprecations are actionable right now. An actionable deprecation is something core deprecated in a previous version that is not supported anymore, so you can update your code to remove the use of that API. Currently Drupal 8.6 and 8.7 are supported, so deprecations there should only be acted on for your custom code. However deprecations in and before 8.5 are entirely fine to act on.

First I counted the top list of deprecated APIs used from Dwayne's data across all of contributed projects. Then I wrote a script to collate api.drupal.org documentation to the deprecation notices. Ideally phpstan itself would report these messages directly and Matt Glaman is working on that. However since that is still blocked on the phpstan side, one needs a different data source to find the deprecation documentation for each occurrence, so I took to api.drupal.org to get that for now. Once that is found, we can categorize the deprecations into actionable, not actionable and actionable for custom code only. For the later case you know which core version you are using, and that should be an up to date minor version. So you don't need to deal with what core branches the community supports otherwise.

The results look really promising so far in terms of how much contributed modules can make progress on even today. If all already actionable deprecations get resolved, there will be very little left at least of the deprecations we already know.

A month ago Dezső Biczó created a set of proof of concept Rector fixes to automate some of these deprecation fixes, so I opened an issue with this new data set to try and cover the top ones that are not just actionable but approachable to automate.

Screenshot of deprecation status PDF

As with all interesting data sets, this summary is just the tip of the iceberg. There is huge potential to mine this data set for other uses, such as finding modules that potential contributors at an event could contribute fixes to. I don't know yet how much I can continue to work with this data myself, and of course others doing analysis of their own would be more than welcome.

Are you a drupal.org project maintainer? Now would be a good time to fill in your Drupal 9 porting information in your project, so you can let contributors know how to best engage with your in the process towards Drupal 9.

https://t.co/hf2ENvlZSo projects can now specify Drupal 9 porting information, so *you* can direct *your* contributors to provide the most valuable help on the way to Drupal 9, fund the process or just step back (for now). Edit your project to help your contributors help you! pic.twitter.com/l1OWwOllBK

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

Disclaimer: The data is based on the state of contributed projects on May 20, 2019 based on Drupal core's 8.8.x development branch on May 20, 2019. The lookup on api.drupal.org was not perfect and I found some bugs there that are being resolved as well so the data gets more accurate. Also, as contributed modules will get updated, there will be less uses of deprecated APIs. As core will introduce more deprecations, the data could get worse. There may also be phpstan Drupal integration bugs or missing features, such as not finding uses of deprecated global constants yet. This is a snapshot as the tools and state of code on all sides evolve, the resulting data will be different.

May 03 2019
May 03

I am about to present about Drupal 9 at DrupalCamp Belarus in May and then at Drupal Developer Days Transylvania in June . I already presented an Acquia webinar with Dries Buytaert on the topic, and was on the Lullabot Podcast discussing Drupal 9 with Angie Byron and Nathaniel Catchpole. I am a firm believer that this know-how should spread as far and wide as possible. I should not be needed to travel around the globe to present the topic and people should not spend the same time again to redo slides for their local presentations. There is no intellectual property here to hide, as many people should be aware and excited and participating as possible. The topic should be presented at Drupal Meetups, Camps, and inside your own companies. So the natural next step for me was to create an open source slideshow.

Screenshot of the first 16 slides of the 1.1 version of the slideshow

I took all that we learned from the webinar and Dries' keynote at DrupalCon Seattle as well as new technology that emerged since then. I also used a free slide template and Google Slides so you can make a copy for yourself and add your own contact information as well as edit the slides down to shorter or longer timeslots. The 51 slides in my test run for about 35 minutes, leaving 10 minutes for discussion in a 45 minute slot. You would likely need to cut content for shorter sessions. There are only basic buildup animations, so if you need to present offline that is also an option. Edit in your contact/introduction info and export and present as PDF.

The 1.0 version of the slides have been presented by Christian Fritsch at DrupalCamp Munich last week and I updated some content to the current 1.1 version as it is available now. I'll keep updating slides based on all your feedback. I shared the slides with public comments allowed, so keep the feedback coming there, comments here or some other way you can get ahold of me.

Resources to watch/listen to learn more include:

  1. Dries' State of Drupal presentation from DrupalCon Seattle
  2. Lullabot Podcast on Drupal 9
  3. Acquia Webinar on Drupal 9

Thanks to Acquia for funding me to create this slideshow and thank you for presenting it!

May 01 2019
May 01

What’s new in Drupal 8.7.0?

This release introduces powerful features that will help us all take Drupal to a whole new level. The new stable JSON:API core module as well as the intuitive and accessible stable Layout Builder are game-changing.

Download Drupal 8.7.0

Layout Builder is stable

The Layout Builder module was originally introduced as an experimental module in Drupal 8.5.0. As of Drupal 8.7.0, Layout Builder is now stable and ready for production use! It provides a powerful, accessible, mobile-friendly page building tool that is fully compatible with revisions, workflows, and in-context previews.

The Layout Builder enables site builders to rapidly create layout templates for content that speed up the development process. It also permits content authors to easily customize individual pages with unique layouts.

The interface allows drag-and-drop management of your content blocks. It additionally supports keyboard controls and toggling the content preview on and off to give the content editor complete control of their experience while building their layouts.

The result of all these features is a state-of-the art content management solution that streamlines mass-production while also supporting unique creation. 123 individuals and 68 organizations contributed to this feature. More than 40 of the individual contributors volunteered some or all of their time.

Check out this demonstration based on the core Umami demo:

The team is working on implementing translation support for layouts in a future release.

New stable JSON:API support

JSON:API support is now included as a stable core feature. The JSON:API specification is an easy and fast way to build decoupled applications. Drupal core's JSON:API module is feature-complete and easy to use with robust out-of-the-box support and simple setup. JSON:API makes it simpler than ever to build ambitious projects. 147 contributors and 76 organizations contributed to this new feature. Among the individual contributors, more than 50 volunteered some or all of their time.

For example, by simply navigating to a URL like https://example.com/jsonapi/node/article, you can get a list of available articles on your site, and filter further from there, to display your Drupal content in decoupled websites, mobile applications, and so on.

Improvements in experimental Media Library

The experimental Media Library has numerous significant improvements in this release. The Media Library is built on top of the stable Media module, which allows reuse of images, documents, and even embedded remote media like YouTube videos. Items in the Media Library can be managed with drag-and-drop. This release improves the design and accessibility of the user interface, allows inline media creation in the library, and provides more flexible grid and table views. 310 contributors and 122 organizations contributed to this new feature. More than 100 individuals volunteered some or all of their time!

Check out this demonstration based the core Umami demo with Media Library enabled:

There are various tasks left to make Media Library stable in a future release, including WYSIWYG integration.

Revisionable menus and taxonomy terms

Custom menu links and taxonomy terms are now revisionable, which allows them to be used in editorial workflows (similarly to nodes, media, and custom blocks). The Entity system now also provides a new Update API to support conversion of further entity types. It supports converting the schema of any content entity type between non-revisionable or non-translatable and revisionable or translatable, which also works when there is pre-existing data for the entity type whose schema is being changed. All these changes improve core support for the Workspaces module.

New features in the Umami demo profile

The Umami food magazine demo is now more accessible and demonstrates more features out of the box, including a new welcome tour, Layout Builder integration for recipes, and multilingual features. The profile now includes a curated set of Spanish translations, and more languages are in the works. 187 contributors and 84 organizations have contributed to Umami, with more than 60 individuals volunteering some or all of their time.

Umami empowers first-time users to spin up a Drupal project in no time so that they can use to evaluate Drupal and learn about its major components.

On the way to Drupal 9

Drupal 8.7.0 includes optional support for Twig 2 (for sites that can patch their Composer configuration). Optional support for Symfony 4 also received a lot of contributions and should be complete in 8.8. This is important work, because Drupal 9 is planned for June 3, 2020 and will update various dependencies, primarily Symfony. Testing Drupal with updated third-party dependencies will help us get better feedback on our compatibility with these dependencies and any difficulties sites encounter when upgrading.

What does this mean for me?

Drupal 8 site owners

Update to 8.7.0 to continue receiving bug fixes. The next bugfix release (8.7.1) is scheduled for June 5, 2019. (See the release schedule overview for more information.) As of this release, sites on Drupal 8.5 will no longer receive security coverage. (Drupal 8.6 will continue receiving security fixes until December 4, 2019.)

Note that new Drupal 8.7.0 installs now require at least PHP 7.0.8. Existing sites still work on at least PHP 5.5.9 for now, but will display a warning. Drupal security updates will begin requiring PHP 7 as early as Drupal 8.8.0 (December 2019), so all users are advised to update to at least PHP 7.0.8 now.

Updating your site from 8.6.15 to 8.7.0 with update.php is exactly the same as updating from 8.6.14 to 8.6.15. Drupal 8.7.0 also has updates to several dependencies. Modules, themes, and translations may need updates for these and other changes in this minor release, so test the update carefully before updating your production site. Read the 8.7.0 release notes for a full list of changes that may affect your site.

Drupal 6 and 7 site owners

Drupal 7 is fully supported by the community until November 2021, and will continue to receive bug and security fixes throughout this time. From November 2021 until at least November 2024, the Drupal 7 Vendor Extended Support program will be offered by vendors.

Drupal 6 is no longer supported.

You can now use the stable migration path for monolingual Drupal 6 and 7 sites with the built-in upgrade user interface. For multilingual sites, there is experimental support; please keep testing and reporting any issues you may find.

Translation, module, and theme contributors

Minor releases like Drupal 8.7.0 include backwards-compatible API additions for developers as well as new features.

Since minor releases are backwards-compatible, modules, themes, and translations that supported Drupal 8.6.x and earlier will be compatible with 8.7.x as well. However, the new version does include some changes to strings, user interfaces, internal APIs and API deprecations. This means that some small updates may be required for your translations, modules, and themes. Read the 8.7.0 release notes for a full list of changes that may affect your modules and themes.

This release has advanced the Drupal project significantly and represents the efforts of hundreds of volunteers and contributors from various organizations, as well as testers from the Minor release beta testing program. Thank you to everyone who contributed to Drupal 8.7!

Apr 29 2019
Apr 29

Dries Buytaert recently published a great post on how to prepare for Drupal 9. He explains how we build Drupal 9 in Drupal 8 using deprecations and the tools to use to detect use of deprecated code. Acquia funded me and Zoltán Herczog to work on one of the tools in the past few weeks. Zoltán just released the second alpha of Upgrade Status. It is definitely worth a try!

Here is how it works:

The module provides an overview of all the contributed and custom projects you have on a Drupal 8 site. It groups custom modules based on the directory structure and takes contributed projects from the update module. For contributed projects it also displays the available updates information inline. This is because if you keep contributed modules up to date, they should eventually improve Drupal 9 compatibility. We also plan to allow project maintainers to inform users about the best way to engage with them on the way to Drupal 9. This is dependent on new project fields on drupal.org which we plan to use to pull information to this dashboard.

Looking at the project list, the UI allows you to run a report on all of the projects to find any known Drupal 9 incompatibilities. Because running the full report takes a really long time, the UI also allows you to run reports on projects one by one. Or rerun the report on specific projects as you are working on improving their codebase. You can export the full report and each report individually.

The reporting backend and the report output is based entirely on the fantastic work of Matt Glaman on drupal-check at Centarro (formerly Commerce Guys) which is in itself based on phpstan by Ondřej Mirtes. We use the same tools that are used in drupal-check, the best command line tool available to check for deprecation errors (and other code quality issues). If you plan to include Drupal 9 compatibility checking in your build or continuous integration system, then drupal-check is your best bet.

Matt is also working with Ondřej to include the @deprecation annotation text in errors, which would improve the usefulness of the reporting of both tools immensely. Until then Upgrade Status links to api.drupal.org for documentation where you can find the deprecation documentation as well and learn about how to fix it.

The alpha2 version of the module was just released including support for recovering from PHP fatal errors (that legitimately happen in parsing some projects), as well as better chunking of project parsing so huge projects like Drupal Commerce will not result in timeouts or memory limit issues. We plan to improve the interactive experience further as well as fix any bugs reported, so please keep the reports coming. Looking forward to your experience with Upgrade Status!

Feb 28 2019
Feb 28

Drupal 8.7.0-alpha1 will be released the week of March 11

In preparation for the minor release, Drupal 8.7.x will enter the alpha phase the week of March 11, 2019. Core developers should plan to complete changes that are only allowed in minor releases prior to the alpha release. The 8.7.0-alpha1 deadline for most core patches is March 8. (More information on alpha and beta releases.)

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

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

  • All issues filed against 8.6.x will then be migrated to 8.7.x, and subsequent bug reports should be targeted against the 8.7.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 8.7.x and 8.8.x.
    2. Most issues that are only allowed in minor releases will be committed to 8.8.x only. A few strategic issues may be backported to 8.7.x, but only at committer discretion after the issue is fixed in 8.8.x (so leave them set to 8.8.x unless you are a committer), and only up until the beta deadline.

Drupal 8.7.0-beta1 will be released the week of March 25

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 April 15, and we will post further details at that time. See the summarized key dates in the release cycle, allowed changes during the Drupal 8 release cycle, and Drupal 8 backwards compatibility and internal API policy for more information.

Bugfixes and security support of Drupal 8.5.x and 8.6.x

Since September 2018, we have been providing security coverage for the previous minor release as well as the newest minor release.

So, in accordance with our policy, security releases for Drupal 8.6.x will be made available until December 4, 2019 when Drupal 8.8.0 is released. Bugfixes that are not security-related will only be committed until Drupal 8.6.x's final bugfix window on April 3.

Normal bugfix support for Drupal 8.5.x ended in August 2016. However security support is provided for 8.5.x until the release of Drupal 8.7.0 on May 1, 2019.

Feb 06 2019
Feb 06

Traditionally Drupal was developed in two parallel branches. Take the example of Drupal 7 and 8. There was the supported stable branch of Drupal 7 that received bugfixes only and there was a development branch of Drupal 8 where developers went free to change and improve things the way they have seen best. As the development of Drupal 8 was nearing release, contributed module and theme authors were asked to take a look and release new versions as well in preparation. While the new branch was built with great care, it was not proven yet in various production environments. It also often took quite some time for contributed modules and themes to update.

Drupal 7 to Drupal 8 API update
Traditional Drupal code vs. module compatibility

Drupal 9 gets built in Drupal 8

With Drupal 8 however, we adopted a key change in our process. Instead of working on Drupal 9 in its own confined space, we work on it within Drupal 8. What does that mean? Drupal 8 allows new backwards compatible changes and additions as well as provides ways to mark outdated functionality as deprecated. This means that Drupal 9 is built step by step in Drupal 8 and so large parts of it are already running in production environments.

There are various good reasons for this. We get our improvements into user's hands much faster this way and also get validation of the new additions and changes faster. We can improve the version people actually use while creating the next version. It hopefully also means that modules and themes get updated with the new better APIs. This way the upgrade effort is spread out from one big upgrade to several smaller ones for site owners and contributed project developers alike. Ultimately this will lead to an easy and relatively small upgrade path to Drupal 9, because Drupal 9 will mainly be updating dependencies and cleaning up our codebase by removing deprecated APIs.

Keeping module/theme/custom code up to date

So theoretically contributed modules and themes and custom code could follow this update process:

Drupal 8.x to Drupal 8.x and 9 API updates
Contributed module that keeps up with core updates

This sounds good in theory, however it is worth thinking about a bit. As shown, the simplest case is the module keeps releasing versions of its own with new features and bugfixes (those are the gaps in numbers between versions shown), while it also updates regularly to new core APIs in the same stream. This is not a problem at all if it is about your custom code and you have full control over the site being deployed to. However it could lead to problems for users of modules and themes.

If you closely follow new core APIs, that also means that you keep updating the required core version number for your code. While Drupal 8.7 may be backwards compatible to Drupal 8.6, once you start using the new things from Drupal 8.7 you are not compatible with lower version numbers anymore. Keeping Drupal 8's one year security support for minor versions in mind, that also means that you would force people using your updated code to update from a Drupal core version that is otherwise security supported just to receive bugfixes as well for the module.

I would say that is fine as long as you only drop support for core versions that are not supported anymore (out of the one year support period), because sites should not be running those anyway. Any security fixes will only be released for the supported versions.

Alternatively a contributed module or theme may consider opening new branches for each core compatibility change. That puts a lot of burden on the maintainer, to keep fixing 8.x-4.x, 8.x-5.x, etc. bugs as well and I would say likely would die off the same way core support gets removed.

Why not do it all at once?

So why not do it the same way contributed module and theme developers always did? All at once!

That is exactly what we are trying to avoid. While Drupal 9 will be mostly the same as Drupal 8 (no new paradigms of development, etc.), the extent of deprecated code will not be trivial to process all at once. We only get the changes proven and Drupal 9 battle tested if developers do keep their code updated. That is why we keep publishing change notices, marking deprecated code and build tooling to support the process. If you are to do everything at once after Drupal 8.8 is released at the end of 2019 you will have quite a limited time to update before Drupal 9 is released 6 months later. For simpler modules and themes this may not be an issue, but for code with some complexity, it is best to start assessing now.

How to figure out what work am I up to?

1. If your code has automated tests, great! Not just great for the tests themselves, but because you can use deprecation testing to find issues. This will not exactly prove that your code is ready for Drupal 9 but if it is not, that will be revealed. Once you fix the issues found, you will be a few steps closer.

2. An additional tool even if you have automated tests, but especially if you don't is static code analysis. Matt Glaman implemented Drupal integration for PHPStan to do deprecation testing effectively. The good thing about this is that it relies on phpdoc annotations, which core consistently uses (as opposed to the tests which rely on trigger_error() that is missing still in many places). This is great for your custom code especially.

For example, Dries recently ran Matt's tools on his site's custom code and fixed his issues:

3. Finally we have a third path under discussion where your live site would record use of deprecated code. This could find some more deprecated code use on top of what is found with tests and static analysis. A tool like this could empower site builders to asses Drupal 9 readiness as well while the prior two methods are entirely developer focused.

Working with core and contributed project maintainers

Drupal core has various issues to properly mark deprecated code now and then clean up our technical debt once Drupal 9 opens (eg. remove deprecated modules). Please search the issue queue and submit issues when existing ones are not found. The api.drupal.org listing is a good place to start to help clean up our own use of deprecated code.

Some of the methods above will get you deprecated code use in a contributed modules or themes you don't maintain. In this case it is best to coordinate with the maintainer. Open an issue if there is not one already to remove deprecated code use and discuss next steps with the maintainer. Submitting a report from the phpstan tool or test failures you found would go a long way to help the maintainer asses the extent of work needed. Depending on how many modules does the maintainer own and the extent of work required, they may or may not prefer to keep it up to date every 6 months. Offering your help updating use of deprecated code is the best way to get closer to the outcome you are looking for.

Further opportunities to learn and participate

Comments are welcome on this post. I am also happy to see you on the Drupal 9 meetings every other week in the #d9readiness channel and the Drupal deprecations office hours held by Lee Rowlands and me in the same channel every Thursday. Exact dates and times of meetings are on the Drupal core calendar. If you can make it to DrupalCon Seattle, it would be lovely to meet you at one of the daily Drupal 9 office hours or the "Drupal 9 is coming: Getting your code ready" session.

Dec 17 2018
Dec 17

Drupal 9 is planned to be only 18 months away now, wow! It is already being built in Drupal 8 by marking APIs to be removed in Drupal 9 as deprecated and eventually upgrading some dependency version requirements where needed. Once the Drupal 9 git branch will be open, you will be able to test directly against Drupal 9. That should not stop you from assessing the compatibility of your module with Drupal 9 now. To prepare for compatibility with Drupal 9, you need to keep up with deprecated functionality and watch out for upgraded dependencies (when we know which are those exactly). Of these two, automation can go a long way to help you keep up with deprecated APIs.

What does deprecated code look like?

Deprecations include a trigger_error() call that allows catching when you use deprecated functionality. Here is an abbreviated example from the documentation:

<?php
/**
* [...]
*/
function drupal_clear_css_cache() {
@
trigger_error('drupal_clear_css_cache() is deprecated in Drupal 8.0.0 and will be removed before Drupal 9.0.0. Use \Drupal\Core\Asset\AssetCollectionOptimizerInterface::deleteAll(). See https://www.drupal.org/node/2317841.', E_USER_DEPRECATED);
\
Drupal::service('asset.css.collection_optimizer')->deleteAll();
}
?>

The trigger_error() call here only fires when the error reporting level includes E_USER_DEPRECATED errors, and the message provides full explanation as to what exactly is deprecated, which Drupal version will stop providing it and what should be used instead.

Unfortunately not all deprecated code is yet updated to this standard, but help is more than welcome. We were already deprecating APIs before we instituted the clever trigger_error() format, and the old deprecations need some work to be updated. However usages of those that are already marked are possible to catch with automated testing.

Make tests catch usage of deprecated APIs

Drupal.org has a great automated testing system. Whenever someone uploads a patch for consideration, the test suite of the corresponding project runs and results are posted back on the issue. Changes that fail with the test suite of the project are never committed. You can use this system to try out how far is your contributed module from working on what we currently know to be Drupal 9. Let's see how this works.

First of all, your module should have automated testing enabled. Make sure you have at least one test in your project and configure automated testing for your module on the Automated testing tab of your project page.

Drupal.org's automated testing is driven from an (optional) drupalci.yml file in projects. Core's drupalci.yml file for example always exposes usages of deprecated APIs in test fails. On the other hand, contributed modules are not tested for usages of deprecated functionality by default. (Note no suppress-deprecations: false clauses in the file).

However you can choose to add a drupalci.yml file to your project repository to expose these failures or keep an issue on your project queue with a patch including the file to learn about the failures. Adding the file to your project outright ensures that the project keeps being Drupal 9 compatible as much as possible. On the other hand once a new minor version of Drupal 8 comes out, new deprecations could fail existing releases of your module in this case. If the newly deprecated APIs were replaced with newly added APIs, then fixing those failures would mean you increase the Drupal minor version requirement of your module, thus not being compatible with older minor versions. That may be problematic. For now you can at least add a testing issue to see what you are up to to begin with.

To make your contributed module tests fail when your module uses deprecated functionality, you need to take the default build.yml file for contributed projects and follow the instructions on drupal.org to take the assessment part of the file and add a suppress-deprecations: false directive to each testing section. The resulting file looks like as follows (everything being a straight copy-paste from the assessment section of the default build.yml file other than the deprecations directives). Save this in a drupalci.yml file in the root of your project:

build:
  assessment:
    validate_codebase:
      phplint:
      container_composer:
      csslint:
      eslint:
      phpcs:
    testing:
      run_tests.standard:
        types: 'Simpletest,PHPUnit-Unit,PHPUnit-Kernel,PHPUnit-Functional'
        # Test for Drupal 9 compatibility
        suppress-deprecations: false
      run_tests.js:
        concurrency: 1
        types: 'PHPUnit-FunctionalJavascript'
        # Test for Drupal 9 compatibility
        suppress-deprecations: false
      nightwatchjs:

If you already had a drupalci.yml file, then adapt its content adding the suppress-deprecations: false directives only. Create a patch file out of it for your project, or take mine from https://www.drupal.org/files/issues/2018-12-17/3020957-2.patch, which should be universally applicable to projects that did not have a drupalci.yml before. Once the patch is uploaded to an issue and set to needs review, you will get deprecations results.

My results and what do they mean

I tried this out on Configuration inspector, a module I help maintain, that provides insights about configuration structures and schemas for developers. As a developer focused module, it would be key to have it up to date with Drupal 9 so it will be trivial to use when the time comes. And the results were green, everything passed.

Ok, does that mean my module is Drupal 9 compatible? Well, not really. This method is only capable to tell me if there are incompatibilities, a green result does not guarantee that the module is Drupal 9 compatible. Why?

  • The method is dependent on all of core (and any other contrib dependencies) marking their deprecated code properly. As stated above this is not yet complete even for core. Help with the core issue and encouragement for contributed module authors to adopt the same deprecation format is welcome.
  • There will be more deprecations until Drupal 9 is released, and we don't know yet the full extent of those, so the result can only tell us so much about the present state.
  • Even in the present state, the results only represent code that my contributed module's test suite actually ran from my module. If my test suite is not very thorough (which in this case unfortunately is the case), then I cannot trust this green result either that it proves Drupal 9 compatibility. I know you are better in test coverage for your contributed modules, so your results would be better.
  • Drupal 9 will bring updated dependencies like Symfony 4 or 5, possibly Twig 2, etc. Usage of those dependency APIs directly would only fail tests if they would use the same trigger_error() deprecation mechanism. I believe that is not the case, for example, Symfony has its own Deprecation Detector that uses code sniffing instead of a test suite.

On the other hand if there are failures, those should be genuine compatibility issues that you should fix for Drupal 9 compatibility. Therefore the title of this post: How to automate testing whether your Drupal 8 module is incompatible with Drupal 9?

Keep in mind that some failures may be results of contributed module dependencies of your module not being up to date. You may not be able to do anything with those failures directly, however letting the maintainer know and submitting fixes to those projects is very welcome.

How will this improve in the future?

As more code in core and contributed modules is marked properly deprecated with the current standard, more of the incompatibilities will be surfaced by this testing method. Also a checkbox for Drupal 9 deprecation testing is planned to be added to the automated testing configuration screen of projects, to make it easier to configure environments to test for deprecated code use. That will make the drupalci.yml creation of this tutorial obsolete, but all caveats and conclusions will still apply.

How does this test work out for your module?

Sep 05 2018
Sep 05

What's new in Drupal 8.6.0?

The most significant update to Drupal 8 in its history, this new release includes two new easy ways to install Drupal, a cooking magazine demo, oEmbed media support, stable upgrades for monolingual Drupal sites, a new media library and workspaces experimental modules, significant layout improvements, various REST fixes and testing improvements.

Download Drupal 8.6.0

oEmbed for media and a new experimental media library

New in this version is built-in stable oEmbed support for media. A new Remote video media type is shipped preconfigured to support embedding YouTube and Vimeo videos.

Media library with multiple images

In a new experimental module, you can now browse existing media and add new media using an integrated widget. Adding multiple media at once is also supported. The media library is based on Views and may be customized.

Umami food magazine demo included

Drupal 8.6.0 offers a new demo profile and theme in the installer. A beautiful, modern demonstration of Drupal's capabilities using an imaginary cooking site named Umami. Drupal's data modeling, listing, page composition and content moderation capabilities are showcased. Sample author and magazine editor users are created to experience different aspects of using Drupal's content management interface. People are invited to tinker with the demo and learn general Drupal concepts and practices.

Umami food magazine demo

The demo profile and theme should not be used on (or as a basis of) actual production or development sites since no backwards compatibility or upgrade paths are provided. Future versions of Umami will demonstrate multilingual capabilities, and as they become stable: media handling, layouts and so on.

New experimental workspaces module

The existing content moderation functionality is great when you need to move individual pieces of content through an editing and approval workflow. For example, use states like Draft, Archived, and Published, and specify which roles have the ability to move content between states.

Workspaces user interface in Drupal 8.6

When "packages" of content (maybe a few, a few hundred or even a few thousand items) need to be reviewed and deployed at once, you'll find the new experimental Workspaces module invaluable. Define multiple workspaces, make changes and deploy between them with an intuitive user interface.

Much improved experimental layout capabilities

The experimental Layout Builder module now supports per-display customizations (e.g. full mode vs. search result), so instead of defining the order of fields stacked on top of each other there, you can define layouts with dynamic sections. It is also possible to create one-off blocks now for use in a specific layout, which will not show up in the global block list. This is useful for things like a promotion only visible within a single landing page.

Stable upgrades for monolingual sites, multilingual improved

Migration support has been steadily improving. This release sees both Migrate Drupal (migrations from previous major Drupal versions) as well as Migrate Drupal UI (upgrade user interface) modules go stable. This means that, if you have a monolingual Drupal 6 or 7 site, you can now use a supported and built-in user interface to migrate your site to Drupal 8.

Multilingual migrations are still experimental and now wrapped in the Migrate Drupal Multilingual module. Significant improvements in this area include support for Drupal 7 Entity Translation migrations for nodes with Title module support. Further testing and implementation of the missing pieces is still required for this module to become stable.

We also saw lots of improvements in migrations for contributed modules in the past six months. Many of the most popular modules, Paragraphs, Field Collections, Multifield, Media, Workflow, and more all have some level of support.

Two new easy ways to install Drupal

Drupal depends on various external tools. To make it significantly easier to start a quick evaluator or development environment, a quick-start command is now included that only needs PHP on the system. Using the built-in webserver in PHP and the SQLite database, it sets up Drupal quickly and opens a browser ready to use:

$ curl -sSO https://www.drupal.org/download-latest/zip
$ unzip drupal-x.y.z.zip
$ php drupal-x.y.z/core/scripts/drupal quick-start
18/18 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓]
Congratulations, you installed Drupal!
Username: admin
Password: NlH5cmfEzsbS3DSs
Drupal development server started: <http://127.0.0.1:8888>
This server is not meant for production use.
One time login url: <http://127.0.0.1:8888/user/reset/1/1525772031/pyK4gRFkQSGGKJk0GhZRucybqROZ2zvV85JwQiD3bFY/login>
Press Ctrl-C to quit the Drupal development server.

The installer now also recognizes existing configuration and provides an option to install from that configuration. This allows to rebuild a site (without its content) locally for development.

MySQL 8 now supported

MySQL 8 includes several performance improvements and language/collation support changes. Drupal 8.6.0 supports MySQL 8. There are no plans to change database version requirements at this time.

Testing and REST improvements

The process of porting all tests from our own Simpletest implementation to PHPUnit is almost done. We have a total of 3,215 tests based on PHPUnit while 68 remain based on Simpletest in this release. The JavaScript testing system is also greatly improved by added support for Nightwatch.js, which supports writing automated tests in JavaScript itself. It is also now possible to upload files in REST requests among many other important bug fixes and improvements.

What does this mean for me?

Drupal 8 site owners

Update to 8.6.0 to continue receiving bug and security fixes. The next bugfix release (8.6.1) is scheduled for October 3 2018.

Updating your site from 8.5.6 to 8.6.0 with update.php is exactly the same as updating from 8.5.5 to 8.5.6. Drupal 8.6.0 also has updates to several dependencies. Modules, themes, and translations may need updates for these and other changes in this minor release, so test the update carefully before updating your production site.

Note that Drupal 8 will require PHP 7 starting in March 2019. If your site is hosted on PHP 5.5 or 5.6, you should begin planning to upgrade (and consider upgrading to PHP 7.2 for best results). See the Drupal core announcement about the PHP 5 end-of-life for more information.

Drupal 6 and 7 site owners

Drupal 7 is still fully supported and will continue to receive bug and security fixes throughout all minor releases of Drupal 8. Drupal 6 is no longer supported. You can now use the stable migration path for monolingual sites with the built-in upgrade user interface. For multilingual sites, please keep testing and reporting any issues you may find.

Translation, module, and theme contributors

Minor releases like Drupal 8.6.0 include backwards-compatible API additions for developers as well as new features. Read the 8.6.0 release notes for more details on the improvements for developers in this release.

Since minor releases are backwards-compatible, modules, themes, and translations that supported Drupal 8.5.x and earlier will be compatible with 8.6.x as well. However, the new version does include some changes to strings, user interfaces, internal APIs and API deprecations. This means that some small updates may be required for your translations, modules, and themes.

Thank you to everyone who contributed to Drupal 8.6!

Apr 24 2018
Apr 24

Maybe you have seen Dries Buytaert's DrupalCon keynote and are looking forward to all the goodies coming in future Drupal 8 versions. The truth is none of those things will happen without people who want to make them happen to solve their own challenges with implementing and showcasing Drupal solutions. Are you implementing decoupled solutions and have issues you are working on? In the middle of building up a suite of integrated media solutions? These core team meetings are ideal to bring in these issues and discuss solutions and to be part of shaping up where Drupal 8 is heading. Read on for details.

  1. There is a weekly meeting on all API first work (REST, Waterwheel, JSON API, GraphQL) every Monday 2pm UTC on Google Hangouts. A link to the current hangout is posted 5 minutes before the meeting in the #drupal-wscci IRC channel.
  2. The Out of the box/demo team also meets every Monday at 3pm UTC on Google Hangouts.
  3. The Javascript office hours are held weekly in https://drupal.slack.com/archives/javascript every Monday at 4:30pm UTC. Get an invite at http://drupalslack.herokuapp.com/.
  4. The Layout Initiative meeting is on every Tuesday at 5pm UTC in https://drupal.slack.com/archives/layouts, get an invite at http://drupalslack.herokuapp.com/.
  5. The usability meeting is every week at 7:30pm UTC on Tuesday at https://drupal.slack.com/archives/ux, get an invite at http://drupalslack.herokuapp.com/.
  6. There is a media meeting every Wednesday at 2pm UTC, join at https://drupal.slack.com/archives/media, get an invite at http://drupalslack.herokuapp.com/.
  7. Wanna help with migrate? The team either meets in Google Hangouts or the #drupal-migrate IRC channel. (Discussed at the start of the meeting based on lead availability in IRC). Meetings are on Thursdays 9pm UTC and 2pm UTC on a weekly alternating basis.

Below is the calendar of all the meetings, subscribe to the Ical feed at https://calendar.google.com/calendar/ical/happypunch.com_eq0e09s0kvcs7v5...

Apr 24 2018
Apr 24

Maybe you have seen Dries Buytaert's DrupalCon keynote and are looking forward to all the goodies coming in future Drupal 8 versions. The truth is none of those things will happen without people who want to make them happen to solve their own challenges with implementing and showcasing Drupal solutions. Are you implementing decoupled solutions and have issues you are working on? In the middle of building up a suite of integrated media solutions? These core team meetings are ideal to bring in these issues and discuss solutions and to be part of shaping up where Drupal 8 is heading. Read on for details.

  1. There is a weekly meeting on all API first work (REST, Waterwheel, JSON API, GraphQL) every Monday 2pm UTC on Google Hangouts. A link to the current hangout is posted 5 minutes before the meeting in the #drupal-wscci IRC channel.
  2. The Out of the box/demo team also meets every Monday at 3pm UTC on Google Hangouts.
  3. The Javascript office hours are held weekly in https://drupal.slack.com/archives/javascript every Monday at 4:30pm UTC. Get an invite at http://drupalslack.herokuapp.com/.
  4. The Layout Initiative meeting is on every Tuesday at 5pm UTC in https://drupal.slack.com/archives/layouts, get an invite at http://drupalslack.herokuapp.com/.
  5. The usability meeting is every week at 7:30pm UTC on Tuesday at https://drupal.slack.com/archives/ux, get an invite at http://drupalslack.herokuapp.com/.
  6. There is a media meeting every Wednesday at 2pm UTC, join at https://drupal.slack.com/archives/media, get an invite at http://drupalslack.herokuapp.com/.
  7. Wanna help with migrate? The team either meets in Google Hangouts or the #drupal-migrate IRC channel. (Discussed at the start of the meeting based on lead availability in IRC). Meetings are on Thursdays 9pm UTC and 2pm UTC on a weekly alternating basis.

Below is the calendar of all the meetings, subscribe to the Ical feed at https://calendar.google.com/calendar/ical/happypunch.com_eq0e09s0kvcs7v5...

Apr 07 2018
Apr 07

DrupalCon Nashville includes a full track of core conversations where you can learn about current topics in Drupal core development, and a week of sprints where you can participate in shaping Drupal's future.

In addition to the core conversations, we have a few meetings on specific topics for future core development. These meetings will be very focused, so contact the listed organizer for each if you are interested in participating. There are also birds-of-a-feather (BoF) sessions, which are open to all attendees without notice.

Also be sure to watch Dries' keynote for ideas about Drupal's future! Check out the extended Dries Q&A session on Thursday as well to get even more questions answered.

Time Topic Organizer Monday, 9 April, 10:00 Configuration validation to support REST and JS Wim Leers Tuesday, 10 April, 10:45 Improving Drupal's evaluator experience (BoF)tedbow Tuesday, 10 April, 15:45 Layout Initiative meeting (BoF)tim.plunkett Wednesday, 11 April, 10:45 Official local development environment (BoF)tedbow Wednesday, 11 April, 14:15 Media roadmap meeting phenaproxima Friday, 13 April, 09:00 Release cycle changes discussion (only core committers) Gábor Hojtsy Friday, 13 April, 11:00 Automated security updateshestenet
Mar 07 2018
Mar 07

What's new in Drupal 8.5.0?

This new version makes Media module available for all, improves migrations significantly, stabilizes the Content Moderation and Settings Tray modules, serves dynamic pages faster with BigPipe enabled by default, and introduces a new experimental entity layout user interface. The release includes several very important fixes for workflows of content translations and supports running on PHP 7.2.

Download Drupal 8.5.0

Media in core improved and available to all site builders

In Drupal 8.4, we added a Media API to core that drew on work from the contributed Media Entity module, but the module was hidden from the user interface due to user experience issues. In Drupal 8.5, many of the usability issues have been addressed, and the module now can be enabled normally. Media in Drupal 8.5 supports uploading and playing audio and video files, as well as listing and reusing media.

For an optimal user experience, we suggest enhancing the core feature set with the rich ecosystem of contributed modules that extends the core Media module. In future releases, we will improve the core user experience with a media library and other tools, add WYSIWYG integration, add support for remote media types like YouTube videos, and provide an upgrade path for existing basic File and Image field data on existing sites.

Settings Tray and Content Moderation now stable

Two experimental modules originally added with Drupal 8.2.0 have been steadily improving in past releases and are now stable. The Settings Tray module provides a quick solution to manage settings in context, such as moving items around in a menu block. The Content Moderation module allows defining content workflow states such as Draft, Archived, and Published, as well as which roles have the ability to move content between states. Drupal 8.5.0 also adds support for translations to be moderated independently.

New experimental Layout Builder module

The new experimental Layout Builder module provides display layout capabilities for articles, pages, user profiles, and other entity displays. Layout Builder uses the same "outside-in" user interface that Settings Tray module does, allowing site builders to edit their layouts on the actual page (rather than having to go to a separate form on the backend). The current user interface is a basic implementation but we expect it will improve significantly in the coming months.

Demonstration of placing blocks with the Layout Builder

Big steps for migrations

After over four years of work, this release marks the Migrate system's architecture stable. The Drupal Migrate and Drupal Migrate UI modules are also considered stable for upgrading monolingual sites. (Multilingual site upgrades are still not fully supported.) Support for incremental migrations is also included in this release. See the migrate announcement for further details on migrating to Drupal 8.

BigPipe by default

The BigPipe module provides an advanced implementation of Facebook's BigPipe page rendering strategy for greatly improved perceived performance for pages with dynamic, personalized, or uncacheable content. The module was added in Drupal 8.1.0 experimentally and became stable in Drupal 8.3.0. Following real-world testing, Big Pipe is now included as part of Drupal 8.5.0's Standard installation profile, so that all Drupal 8 sites will be faster by default. BigPipe is also the first new Drupal 8 feature to mature from an experimental prototype all the way to being part of a standard installation!

Groundwork for a Drupal 8 "Out of the Box" demo

Drupal 8.5.0 includes the groundwork for a new demo profile and theme from the Out of the Box Initiative, which will be a beautiful, modern demonstration of Drupal's capabilities. This will allow us to provide the demo experimentally, possibly in a future Drupal 8.5 release. (The demo profile and theme should not be used on actual production or development sites since no backwards compatibility or upgrade paths are provided.) If you'd like to see this demo in action, you can also see it in the 8.6.x development version.

PHP 7.2 now supported

Drupal 8.5.0 now runs on PHP 7.2, which comes with new features and improves performance over PHP 7.1. PHP 7.2 is now the recommended PHP version to use with Drupal 8.

What does this mean for me?

Drupal 8 site owners

Update to 8.5.0 to continue receiving bug and security fixes. The next bugfix release (8.5.1) is scheduled for April 4, 2018.

Updating your site from 8.4.5 to 8.5.0 with update.php is exactly the same as updating from 8.4.4 to 8.4.5. Drupal 8.5.0 also has updates to several dependencies, including a backwards-compatible update to a Symfony long-term-support release (which will be supported for many years). Modules, themes, and translations may need updates for these and other changes in this minor release, so test the update carefully before updating your production site.

Note that Drupal 8 will require PHP 7 starting in March 2019, one year from now. If your site is hosted on PHP 5.5 or 5.6, you should begin planning to upgrade (and consider upgrading to PHP 7.2 now that it is supported). See the Drupal core announcement about the PHP 5 end-of-life for more information.

Drupal 6 and 7 site owners

Drupal 7 is still fully supported and will continue to receive bug and security fixes throughout all minor releases of Drupal 8. Drupal 6 is no longer supported. See the migrate announcement for further details on migrating to Drupal 8.

Translation, module, and theme contributors

Minor releases like Drupal 8.5.0 include backwards-compatible API additions for developers as well as new features. Read the 8.5.0 release notes for more details on the improvements for developers in this release.

Since minor releases are backwards-compatible, modules, themes, and translations that supported Drupal 8.4.x and earlier will be compatible with 8.5.x as well. However, the new version does include some changes to strings, user interfaces, internal APIs and API deprecations. This means that some small updates may be required for your translations, modules, and themes. See the announcement of the 8.5.0 release candidate for more background information.

Mar 07 2018
Mar 07

After over four years of work with over 570 contributors and 1300+ closed issues, Drupal 8.5.0 releases the Migrate system's architecture as fully stable. This means that developers can write migration paths without worrying for stability of the underlying system.

On top of that the Migrate Drupal and Migrate Drupal UI modules (providing Drupal 6 and 7 to Drupal 8 migrations) are considered stable for upgrading monolingual sites. All of the remaining critical issues for the Migrate Drupal module's upgrade paths and stability are related to multilingual migration support (so multilingual site upgrades are still not fully supported).

Support for incremental migrations is now also available, which means that site owners can work gradually on their new Drupal 8 site while content is still being added to the old site. When migrations (including incremental migrations) are run through the user interface, site owners will now see a warning if some data on the Drupal 8 site might be overwritten. (A similar fix for Drush is not yet available, so be careful not to overwrite data if you run a migration on the command line.) 

Upgrade instructions for Drupal 6 and Drupal 7 sites can be found in the Upgrading to Drupal 8 handbook. Your old site can still remain up and running while you test migrating your data into your new Drupal 8 site. If you happen to find a bug, that is not a known migrate issue, your detailed bug report with steps to reproduce is a big help!

Unlike previous versions, Drupal 8 stores translated content as single entities. Multilingual sites with reference fields (node_reference, entity_reference) or multilingual menus can upgrade to Drupal 8 using Drush, executing the desired migrations one by one. In this process you need to create and run a series of additional custom migrations to reflect the new entity identifiers assigned during earlier migrations. There is no automation implemented for this process yet.

Data can be migrated to Drupal 8 also from non-Drupal sources such as CSV, XML, JSON, or directly from 3rd party systems' databases. For instructions and examples, refer to Migrate API handbook.

Huge thanks again to all the contributors who made this possible.

List of Migrate contributors

Feb 26 2018
Feb 26

The first release candidate for the upcoming Drupal 8.5.0 release is now available for testing. Drupal 8.5.0 is expected to be released March 7.

8.5.x makes the Media module available for all, improves migrations significantly, stabilizes the Content Moderation and Settings Tray modules, serves dynamic pages faster with BigPipe enabled by default, and introduces the new experimental Layout Builder module. The release includes several very important fixes for workflows of content translations and supports PHP 7.2. Finally, 8.5.0-rc1 also includes the same security updates that are provided in 8.4.5.

What does this mean to me?

For Drupal 8 site owners

Drupal 8.4.5, a security update and the final release of the 8.4.x series, has also been released this week. 8.4.x sites should update immediately to 8.4.5, but going forward, 8.4.x will receive no further releases following 8.5.0's release date, and sites should prepare to update from 8.4.x to 8.5.x in order to continue getting bug and security fixes. Use update.php to update your 8.4.x sites to the 8.5.x series, just as you would to update from (e.g.) 8.4.2 to 8.4.3. You can use this release candidate to test the update. (Always back up your data before updating sites, and do not test updates in production.)

If you're an early tester who is already running 8.5.0-alpha1 or 8.5.0-beta1, you should update to 8.5.0-rc1 immediately. 8.5.0-rc1 includes security fixes (the same fixes that were released in Drupal 8.4.5).

Site owners should also take note of the fact that Drupal 8's support for PHP 5 will end in one year, in March 2019. PHP 7.2 is now the best recommended PHP version to use with Drupal 8.

For module and theme authors

Drupal 8.5.x is backwards-compatible with 8.4.x. However, it does include internal API changes and API changes to experimental modules, so some minor updates may be required. Review the change records for 8.5.x, and test modules and themes with the release candidate now.

For translators

Some text changes were made since Drupal 8.4.0. Localize.drupal.org automatically offers these new and modified strings for translation. Strings are frozen with the release candidate, so translators can now update translations.

For core developers

All outstanding issues filed against 8.4.x were automatically migrated to 8.5.x. Future bug reports should be targeted against the 8.5.x branch. 8.6.x will remain open for new development during the 8.5.x release candidate phase. The 8.5.x branch will be subject to release candidate restrictions, with only critical fixes and certain other limited changes allowed.

Your bug reports help make Drupal better!

Release candidates are a chance to identify bugs for the upcoming release, so help us by searching the issue queue for any bugs you find, and filing a new issue if your bug has not been reported yet.

Oct 04 2017
Oct 04

What's new in Drupal 8.4.0?

This new version is an important milestone of stability for Drupal 8. It adds under-the-hood improvements to enable stable releases of key contributed modules for layouts, media, and calendaring. Many other core experimental modules have also become stable in this release, including modules for displaying form errors inline and managing workflows.

The release includes several very important fixes for content revision data integrity as well as an update to stop the deletion of orphaned files that was causing data loss for many sites, alongside numerous improvements for site builders and content authors.

Download Drupal 8.4.0

Important: If you use Drush to manage Drupal, be sure to update to Drush 8.1.12 or higher before updating Drupal. Updating to Drupal 8.4.0 using Drush 8.1.11 or earlier will fail. (Always test minor version updates carefully before making them live.)

Inline Form Errors

The Inline Form Errors module provides a summary of any validation errors at the top of a form and places the individual error messages next to the form elements themselves. This helps users understand which entries need to be fixed, and how. Inline Form Errors was provided as an experimental module from Drupal 8.0.0 on, but it is now stable and polished enough for production use.

Screenshot showing form error displayed with the field rather than at the top of the form.

Datetime Range

The Datetime Range module provides a field type that allows end dates to support contributed modules like Calendar. This stable release is backwards-compatible with the Drupal 8.3.x experimental version and shares a consistent API with other Datetime fields. Future releases may improve Views support, usability, Datetime Range field validation, and REST support.

Screenshot showing form elements to specify start and end dates.

Layout Discovery API

The Layout Discovery module provides an API for modules or themes to register layouts as well as five common layouts. Providing this API in core enables core and contributed layout solutions like Panels and Display Suite to be compatible with each other. This stable release is backwards-compatible with the 8.3.x experimental version and introduces support for per-region attributes.

Media API

The new core Media module provides an API for reusable media entities and references. It is based on the contributed Media Entity module.

Since there is a rich ecosystem of Drupal contributed modules built on Media Entity, the top priority for this release is to provide a stable core API and data model for a smoother transition for these modules. Developers and expert site builders can now add Media as a dependency. Work is underway to provide an update path for existing sites' Media Entity data and to port existing contributed modules to the refined core API.

Note that the core Media module is currently marked hidden and will not appear on the 'Extend' (module administration) page. (Enabling a contributed module that depends on the core Media module will also enable Media automatically.) The module will be displayed to site builders normally once once related user experience issues are resolved in a future release.

Similarly, the REST API and normalizations for Media are not final and support for decoupled applications will be improved in a future release.

Content authoring and site administration experience improvements

The "Save and keep (un)published" dropbutton has been replaced with a "Published" checkbox and single "Save" button. The "Save and..." dropbutton was a new design in Drupal 8, but users found it confusing, so we have restored a design that is more similar to the user interface for Drupal 7 and earlier.

Both the "Comments" administration page at `/admin/content/comment` and the "Recent log messages" report provided by dblog are now configurable views. This allows site builders to easily customize, replace or clone these screens.

Updated migrations

This release adds date and node reference support for Drupal 6 to Drupal 8 migrations. Core provides migrations for most Drupal 6 data and can be used for migrating Drupal 6 sites to Drupal 8, and the Drupal 6 to 8 migration path is nearing beta stability. Some gaps remain, such as for some internationalization data. The Drupal 7 to Drupal 8 migration is incomplete but is suitable for developers who would like to help improve the migration and can be used to test upgrades especially for simple Drupal 7 sites. Most high-priority migrations are available.

Moderation and workflows

The Workflows module is now also stable, however it only provides a framework for managing workflows and is not directly useful in itself. The experimental Content Moderation module allows workflows to be applied to content and is now at beta stability. Content moderation workflows can now apply to any entity types that support revisions, and numerous usability issues and critical bugs are resolved in this release.

Platform features for web services

Drupal 8.4 continues to expand Drupal's support for web services that benefit decoupled sites and applications, including a 15% performance improvement for authenticated REST requests, expanded REST functionality, and developer-facing improvements.

Further details are available about each area in the 8.4.0 release notes.

What does this mean for me?

Drupal 8 site owners

Update to 8.4.0 to continue receiving bug and security fixes. The next bugfix release (8.4.1) is scheduled for November 1, 2017.

Updating your site from 8.3.7 to 8.4.0 with update.php is exactly the same as updating from 8.3.6 to 8.3.7. If you use Drush, be sure to update to Drush 8.1.12 or higher before using it to update Drupal 8.3.7 to 8.4.0. Drupal 8.4.0 also has major updates to several dependencies, including Symfony, jQuery, and jQuery UI. Modules, themes, and translations may need updates for these and other changes in this minor release, so test the update carefully before updating your production site.

Drupal 7 site owners

Drupal 7 is still fully supported and will continue to receive bug and security fixes throughout all minor releases of Drupal 8.

Most high-priority migrations from Drupal 7 to 8 are now available, but the migration path is still not complete, especially for multilingual sites, so you may encounter errors or missing migrations when you try to migrate. That said, since your Drupal 7 site can remain up and running while you test migrating into a new Drupal 8 site, you can help us stabilize the Drupal 7 to Drupal 8 migration path! Testing and bug reports from your real-world Drupal 7 sites will help us stabilize this functionality sooner for everyone. (Search the known issues.)

Drupal 6 site owners

Drupal 6 is not supported anymore. Create a Drupal 8 site and try migrating your data into it as soon as possible. Your Drupal 6 site can still remain up and running while you test migrating your Drupal 6 data into your new Drupal 8 site. Core now provides migrations for most Drupal 6 data, but the migrations of multilingual functionality in particular are not complete. If you find a new bug not covered by the known issues with the experimental Migrate module suite, your detailed bug report with steps to reproduce is a big help!

Translation, module, and theme contributors

Minor releases like Drupal 8.4.0 include backwards-compatible API additions for developers as well as new features. Read the 8.4.0 release notes for more details on the improvements for developers in this release.

Since minor releases are backwards-compatible, modules, themes, and translations that supported Drupal 8.3.x and earlier will be compatible with 8.4.x as well. However, the new version does include some changes to strings, user interfaces, and internal APIs (as well as more significant changes to experimental modules). This means that some small updates may be required for your translations, modules, and themes. See the announcement of the 8.4.0 release candidate for more background information.

Sep 07 2017
Sep 07

The first release candidate for the upcoming Drupal 8.4.0 release is now available for testing. Drupal 8.4.0 is expected to be released October 4.

8.4.x includes new stable modules for storing date and time ranges, display form errors inline and manage workflows. New stable API modules for discovering layout definitions and media management are also included. The media API module is new in core, all other new stable modules were formerly experimental. The release also includes several important fixes for content revision data integrity, orphan file management and configuration data ordering among other things. You can read a detailed list of improvements in the announcements of alpha1 and beta1.

What does this mean to me?

For Drupal 8 site owners

The final bugfix release of 8.3.x has been released. A final security release window for 8.3.x is scheduled for September 20, but 8.3.x will receive no further releases following 8.4.0, and sites should prepare to update from 8.3.x to 8.4.x in order to continue getting bug and security fixes. Use update.php to update your 8.3.x sites to the 8.4.x series, just as you would to update from (e.g.) 8.3.4 to 8.3.5. You can use this release candidate to test the update. (Always back up your data before updating sites, and do not test updates in production.)

For module and theme authors

Drupal 8.4.x is backwards-compatible with 8.3.x. However, it does include internal API changes and API changes to experimental modules, so some minor updates may be required. Review the change records for 8.4.x, and test modules and themes with the release candidate now.

For translators

Some text changes were made since Drupal 8.3.0. Localize.drupal.org automatically offers these new and modified strings for translation. Strings are frozen with the release candidate, so translators can now update translations.

For core developers

All outstanding issues filed against 8.3.x were automatically migrated to 8.4.x. Future bug reports should be targeted against the 8.4.x branch. 8.5.x will remain open for new development during the 8.4.x release candidate phase. For more information, see the release candidate phase announcement.

Your bug reports help make Drupal better!

Release candidates are a chance to identify bugs for the upcoming release, so help us by searching the issue queue for any bugs you find, and filing a new issue if your bug has not been reported yet.

Jun 16 2017
Jun 16

Start: 

2017-06-15 (All day) - 2017-06-18 (All day) America/Toronto

Event type: 

Sprint

Several key contributors to the Migrate Initiative will be at the sprint at DrupalCamp Montreal on Sunday (and to some degree on earlier days as well). Join contributors Adam G-H (phenaproxima), Maxime Turcotte (maxocub) and Dave Vasilevsky (vasi) in person. Initiative coordinator Mike Ryan (mikeryan) is also planning to join remotely on Sunday.

Among the most important Migrate critical issues on the table that are planned to be worked on is auditing for potential ID conflicts before upgrading from older versions. This is the most thorny outstanding issue for the initiative. Use cases and feedback in general is welcome. Further migrate issues are categorized and tracked in the Migrate triage spreadsheet (update regularly). These include handling import of private files, adding back support for incremental migrations, redirecting for obsolete content translations when they are merged in the migration, etc. All of those need helping hands and this is a great time to get experienced with help from the most well versed people in the field.

If you cannot join the sprint this time, your involvement is more than welcome anytime. The migrate team has weekly meetings on every Thursday at alternating meeting times. See https://www.drupal.org/node/2735059#meet for the upcoming meetings.

May 19 2017
May 19

The important first step for media support in core just landed in Drupal 8.4.x: a new beta experimental Media module to support storing media of various types. While Drupal core already has generic file upload and image upload support, the new module will support asset reuse and be extensible to support video, remote media, embedding, and so on.

This is a huge testament to individuals and organizations with shared interests pulling together, figuring out how to make it happen in core, and getting it done. 89 individuals (both volunteering their own time and from various companies all across the world) contributed both directly in the core patch and via involvement with the contributed Media Entity module:

That said, this is just the first step. (If you go and enable the core Media module, all it can do right now is give you an error message that no media types can be created.) The next steps are to add a file/document media plugin and an image media plugin so these types of media may be created on the site with the module. Then, widgets and formatters for the upload field and image field interfaces will be added so we can reproduce the existing core functionality with media. Adam Hoenich wrote up a concise summary of the next steps, and granular details are listed in the followup roadmap.

There are definitely more tasks than people available, so your contributions would be more than welcome! Now is the time to make sure media is integrated in a way that your projects can best utilize it. Get involved through the media IRC meetings happening at 2pm GMT every week in #drupal-media. (See https://www.drupal.org/irc for more information on Drupal IRC). Or, if you are available at other times, ask in the channel. The issues are listed on the Media Initiative plan.

Let's put the remaining pieces in place together!

Apr 19 2017
Apr 19

(Disclaimer: Dries did not ask/order/suggest/request me to post this neither to make any changes whatsoever.)

I was reading Drupal Confessions with great interest, because my primary job for quite a while now is to help enable the best efforts in the Drupal community to work together to reach new heights. I am really privileged to be able to do this and make a living out of it, it is the job I always dreamed of. I also hope that I am being useful to the Drupal community in doing so. I kept nodding in agreement with the open letter's statements on diversity so I could not get rid of my cognitive dissonance on their connection with reality for several days now. The open letter says "We ask you to fight for us, Dries, to protect us from intolerance, harassment, smearing, bullying, and discrimination, no matter why or where it originates from."

As someone who is getting a paycheck at least indirectly from Dries in the past 10 years, and working as directly with him as possible in Acquia's Office of the CTO for the second half of that period, I have the opportunity to look at his practices in terms of diversity. Which would be the most observable group to learn more from if not his personal department where he directly appoints people?

In the past 5 years I've been closely working with Dries as a remote employee in the Office of the CTO at Acquia, which consisted of 15 people at most at any given time. In this time I worked with at least the following types of people directly in this group (in random order): blind, stutterer, person with ADHD, person with serious sleep problems, person with even more serious sleep problems, divorced, gay, bi, lesbian, asexual, polyamorous, gospel singer, BDSM, religiously raised, atheist, clinically infertile, cosplayer, very tall, short, people from Eastern Europe, Western Europe, US and India, native-borns, immigrants, people in offices, people always working remotely, capitalist, socialist, pacifist, people from a military family, adopting parent, transgender, people with tics, people who don't drink alcohol, etc. The teams I worked on usually had relatively high percentage of women in technical roles. My current team is 50% female, and 1/3rd of the department overall is female. This could not happen by accident.

While none of this represent the whole rainbow of humanity, and it could definitely be further improved, our limited group of 15 people already covered outstanding diversity in my view. Also this is a group that cares, we discuss and live through our struggles and support each other on every step where we can. I would challenge many of those signing the open letter to practice this kind of diversity in their teams. I for one really enjoy the varying values that people brought in and am sad that some of those great people have left to pursue other technical challenges.

In this five years, I never experienced that when hiring people either of these things were considered as a negative or that any person was treated or felt treated badly for any personal life matter. Neither that any of the amazing people who unfortunately left and are covered in the list left because of any of those.

Given that I just cannot get over my cognitive dissonance. Who are being convinced of what?

Apr 05 2017
Apr 05

Drupal 8.3.0, the third minor release of Drupal 8, is now available. With Drupal 8, we made significant changes in our release process, adopting semantic versioning and scheduled feature releases. This allows us to make extensive improvements to Drupal 8 in a timely fashion while still providing backwards compatibility.

Update: Drupal 8.3.1 is available and fixes a security vulnerability. You should update directly to 8.3.1 instead of 8.3.0.

What's new in Drupal 8.3.0?

This new version includes improvements to authoring experience, site administration, REST support, and a stable version of the BigPipe module. It also includes new experimental modules to abstract workflow functionality, to lay out content types differently (e.g. articles are two column vs. press releases are three column), and to provide a general layout API for contributed modules. Many smaller improvements for the experimental Content Moderation module are included as well. (Experimental modules are provided with Drupal core for testing purposes, but are not yet fully supported.)

Download Drupal 8.3.1

New and improved content authoring

Drupal 8.3 ships with the updated CKEditor 4.6, which contains a host of improvements, including better paste from Word, and a new default skin that better matches Drupal's Seven administration theme. We've also added the AutoGrow plugin, to better utilize larger screen sizes.

CKEditor 4.6 with AutoGrow and new default skin.

Quick editing images now supports drag and drop.

Drag and drop image replacement

Site building and administrative improvements

Drupal 8.3 ships with a redesigned admin status report, to better surface important status messages for your site.

Redesigned status report page

Other incremental enhancements include:

  • The Views listing page is now standardized with other administrative listings.
  • The "Allowed HTML tags" input has been converted to a textarea, which significantly improves the usability of HTML filter configuration (and thereby makes it easier to configure filters securely.)
  • The Content and People overview pages' Views filters have been rearranged to match the column order of the listing, for more intuitive filtering.
  • Image fields are now limited to only accepting images, so that users on mobile clients are not offered a confusing and non-functional video upload option.

BigPipe for perceived performance

The Drupal 8 BigPipe module (now stable!) provides an advanced implementation of Facebook's BigPipe page rendering strategy, leading to greatly improved perceived performance for pages with dynamic, personalized, or uncacheable content. See the BigPipe documentation.

[embedded content]

The core BigPipe improvements introduced in 8.3.0 are also utilized by the Sessionless BigPipe contributed module to use the same technique for serving the first (yet uncached) response to anonymous visitors.

Platform features for web services

Drupal 8.3 continues to expand Drupal's support for web services that benefit decoupled sites and applications, with bug fixes, improved responses, and new features. It is now possible to register users from the REST API, 403 responses now return a reason why access was denied, for greatly improved developer experience, and anonymous REST API performance has been increased by 60% when utilizing the internal page cache. The REST API also got a massive overhaul of its test coverage.

Experimental: Choose different form and view display layouts for your entity types

The new experimental Field Layout module provides the ability for site builders to rearrange fields on content types, block types, etc. into new regions, for both the form and display, on the same forms provided by the normal field user interface.

Field Layout also uses the new the Layout Discovery module, which provides an API for modules or themes to register layouts as well as five common default layouts. By providing this API in core, we help make it possible for core and contributed layout solutions to be compatible with each other. The following contributed modules already have development versions that support the new API:

Drupal 8.3.0 Field Layout screens

Experimental: Content moderation improvements

The Content Moderation module included with Drupal 8.2.x is now accompanied by a more abstract Workflows module that took over the underlying workflow functionality and API. This allows additional modules to apply workflows that do not deal with content publication, such as for users or products. The Workflows module provides a user interface to package states with their transitions in a workflow, which Content Moderation can then apply to content, making configuration much easier.

There are several other smaller improvements. It is now possible to moderate non-translatable entity types, entity types without bundles, and any entity type that supports publishing (not just nodes). Moderation states are also reverted when revisions are reverted.

Workflow edit screens in Drupal 8.3.0

What does this mean to me?

Drupal 8 site owners

Update to 8.3.0 to continue receiving bug and security fixes. The next bugfix release (8.3.1) is scheduled for May 3, 2017.

Updating your site from 8.2.7 to 8.3.0 with update.php is exactly the same as updating from 8.2.6 to 8.2.7. Modules, themes, and translations may need small changes for this minor release, so test the update carefully before updating your production site.

Drupal 7 site owners

Drupal 7 is still fully supported and will continue to receive bug and security fixes throughout all minor releases of Drupal 8.

Most high-priority migrations from Drupal 7 to 8 are now available, but the migration path is still not complete, especially for multilingual sites, so you may encounter errors or missing migrations when you try to migrate. That said, since your Drupal 7 site can remain up and running while you test migrating into a new Drupal 8 site, you can help us stabilize the Drupal 7 to Drupal 8 migration path! Testing and bug reports from your real-world Drupal 7 sites will help us stabilize this functionality sooner for everyone. (Search the known issues.)

Drupal 6 site owners

Drupal 6 is not supported anymore. Create a Drupal 8 site and try migrating your data into it as soon as possible. Your Drupal 6 site can still remain up and running while you test migrating your Drupal 6 data into your new Drupal 8 site. Core now provides migrations for most Drupal 6 data, but the migrations of multilingual functionality, references, and dates in particular are not complete. If you find a new bug not covered by the known issues with the experimental Migrate module suite, your detailed bug report with steps to reproduce is a big help!

Translation, module, and theme contributors

Minor releases like Drupal 8.3.0 include backwards-compatible API additions for developers as well as new features. Read the 8.3.0 release notes for more details on the improvements for developers in this release.

Since minor releases are backwards-compatible, modules, themes, and translations that supported Drupal 8.2.x and Drupal 8.1.x will be compatible with 8.3.x as well. However, the new version does include some changes to strings, user interfaces, and internal APIs (as well as more significant changes to experimental modules). This means that some small updates may be required for your translations, modules, and themes. See the announcement of the 8.3.0 release candidate for more background information.

Mar 17 2017
Mar 17

At major Drupal events when various interested parties are in attendance, we usually organize meetings around a few key shared interests, to ensure we are on the same page and make progress on important areas for the benefit of all. At Drupal Developer Days Seville (March 21st to March 25th), we are planning the following meetings:

  • Media Entity core patch review meeting: Tuesday 11:30am to 1:30pm (and likely more)
  • Drupal Product Management team meetings: Wednesday 12:30pm to 3:30pm and Thursday 3:30pm to 5pm
  • Settings tray meeting: Wednesday 4:30pm to 5:30pm
  • File deletion critical issues meeting: Thursday 10am to 11am
  • Major entity issues triage meeting: Friday 11:30am to 12:30pm

There are also 12 focused sprints organized with 50-70 sprinters signed up on any given day throughout the week to advance both core and contributed projects. Interested to join any of the sprints? Look for the leaders and other members of the sprint teams.

Mar 01 2017
Mar 01

The first release candidate for the upcoming Drupal 8.3.0 release is now available for testing. Drupal 8.3.0 is expected to be released April 5.

8.3.x includes new experimental modules for workflows, layout discovery and field layouts; raises stability of the BigPipe module to stable and the Migrate module to beta; and includes several REST, content moderation, authoring experience, performance, and testing improvements among other things. You can read a detailed list of improvements in the announcements of alpha1 and beta1.

What does this mean to me?

For Drupal 8 site owners

The final bugfix release of 8.2.x has been released. A final security release window for 8.2.x is scheduled for March 15, but 8.2.x will receive no further releases following 8.3.0, and sites should prepare to update from 8.2.x to 8.3.x in order to continue getting bug and security fixes. Use update.php to update your 8.2.x sites to the 8.3.x series, just as you would to update from (e.g.) 8.2.4 to 8.2.5. You can use this release candidate to test the update. (Always back up your data before updating sites, and do not test updates in production.)

Drupal 8 release cycle diagram, showing the 8.3.x alpha/beta and RC phases beginning as 8.2.x nears its end in October, and 8.2.x support ending when 8.3.x is released.

For module and theme authors

Drupal 8.3.x is backwards-compatible with 8.2.x. However, it does include internal API changes and API changes to experimental modules, so some minor updates may be required. Review the change records for 8.3.x, and test modules and themes with the release candidate now.

For translators

Some text changes were made since Drupal 8.2.0. Localize.drupal.org automatically offers these new and modified strings for translation. Strings are frozen with the release candidate, so translators can now update translations.

For core developers

All outstanding issues filed against 8.2.x were automatically migrated to 8.3.x. Future bug reports should be targeted against the 8.3.x branch. 8.4.x will remain open for new development during the 8.3.x release candidate phase. For more information, see the release candidate phase announcement.

Your bug reports help make Drupal better!

Release candidates are a chance to identify bugs for the upcoming release, so help us by searching the issue queue for any bugs you find, and filing a new issue if your bug has not been reported yet.

Feb 24 2017
Feb 24

Drupal 8.3.0 release candidate phase

The release candidate phase for the 8.3.0 minor release begins the week of February 27. Starting that week, the 8.3.x branch will be subject to release candidate restrictions, with only critical fixes and certain other limited changes allowed.

8.3.x includes new experimental modules for workflows, layout discovery and field layouts; raises stability of the BigPipe module to stable and the Migrate module to beta; and includes several REST, content moderation, authoring experience, performance, and testing improvements among other things. You can read a detailed list of improvements in the announcements of alpha1 and beta1.

Minor versions may include changes to user interfaces, translatable strings, themes, internal APIs like render arrays and controllers, etc. (See the Drupal 8 backwards compatibility and internal API policy for details.) Developers and site owners should test the release candidate to prepare for these changes.

8.4.x will remain open for new development during the 8.3.x release candidate phase.

Drupal 8.3.0 will be released on April 5th, 2017.

No Drupal 8.2.x or 7.x releases planned

March 1 is also a monthly core patch (bug fix) release window for Drupal 8 and 7, but no patch release is planned. This is also the final bug fix release window for 8.2.x (meaning 8.2.x will not receive further development or support aside from its final security release window on March 15). Sites should plan to update to Drupal 8.3.0 on April 5.

For more information on Drupal core release windows, see the documentation on release timing and security releases, as well as the Drupal core release cycle overview.

Feb 17 2017
Feb 17

We started regular Drupal usability meetings twice a week almost a year ago in March 2016. That is a long time and we succeeded in supporting many key initiatives in this time, including reviews on new media handling and library functionality, feedback on workflow user experience, outside-in editing and place block functionality. We helped set scope for the changes required to inline form errors on its way to stability. Those are all supporting existing teams working on their respective features where user interfaces are involved.

However, we also started to look at some Drupal components and whether we can gradually improve them. One of the biggest tasks we took on was redesigning the status page, where Drupal's system information is presented and errors and warnings are printed for site owners to resolve. While that looks like a huge monster issue, Roy Scholten in fact posted a breakdown of how the process itself went. If we were to start a fresh issue (which we should have), the process would be much easier to follow and would be more visible. The result is quite remarkable:

New status page in Drupal 8.3

While the new status page is amazing, for me the biggest outcome is how eager people were for this refresh and the example we set as to what is possible to do in Drupal 8. We can take a page, redesign it completely and get it released in a minor release for everyone to use! Some feedback on the result:

This looks great! #drupalnerd https://t.co/UgB7C2t3rN

— tiny red flowers (@tinyredflowers) February 12, 2017

Wow, just wow. https://t.co/Slq2bn7AIe

— Thomas Donahue (@dasginganinja) February 9, 2017

It's about damn time! https://t.co/56hGMKfwdQ

— Jerry Low (@jerrylowm) February 8, 2017

Wow! Just wow! Sometimes Christmas comes early. Sweet! https://t.co/9cYQbFdK18

— Adam Evertsson (@AdamEvertsson) February 8, 2017

@DrupalUx pic.twitter.com/BoCp720AUo

— Jan Laureys (@JanLaureys) February 8, 2017

Wow this looks really nice @DrupalUx. https://t.co/tyr6NfNZOm

— Eric Heydrich (@ericheydrich) February 8, 2017

A status page that does justice for the elegance of Drupal 8. Looks very nice! https://t.co/Kt75wR40U6

— David Lanier (@nadavoid) February 8, 2017

THANK YOU, LORD! https://t.co/dVU49QPS6D

— Phéna Proxima (@djphenaproxima) February 8, 2017

My mistakes are now much nicer to look at. Great work @DrupalUx ! pic.twitter.com/7LKNGxI3FA

— dawehner (@da_wehner) February 7, 2017

This is the best https://t.co/vTErYfMVc2

— drupteg (@drupteg) February 7, 2017

If this is not enough proof that we can make significant improvements and that people are more than open to receive them, not sure what else could be it.

To join these efforts, there are several smaller things in the works currently, including improving the bulk operations UI on views forms (or for the more adventurous redesigning filters and bulk operations, which would affect the content, users and even the media admin pages). We are working to update the throbber in the Seven theme, make the add content link finger friendly, and so on. There are many smaller to bigger issues for anyone to work on, we can match you with an issue. We need designers, developers, testers, etc.

Want to be a part of the next celebrated improvement? Join the UX slack on drupal.slack.com (get an invite at http://drupalslack.herokuapp.com/). Meetings are 9pm CEST every Tuesday and 9am CEST every Wednesday. See you there!

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web