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!

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. One of the tools I worked heavily on with Zoltán Herczog in the past few weeks is Upgrade Status, and Zoltán just released the alpha2 version. 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!

Feb 17 2017
Feb 17

Now that Drupal 8.3 is in beta, it is time to look at progress around core initiatives again and see how you can help move one or more of them forward. Once again I asked initiative contributors to help compile this post to inform you all of progress across the board. This is just a sampling of some improvements, there are a lot more that we could not cover here.

Default content and new core theme

The default content and new core theme teams decided to join forces because the goals are intertwined. The teams found it hard to demonstrate good default content without a supporting visual look and vice versa. The plan to go with a farmer's market site changed to a more general publication site, but that still allows for plenty of things to showcase. We are looking for a designer / art director for the project (deadline today!).

Use the Slack channel if you want to help or if you just want to follow our progress. Get an invite at https://drupaltwig-slack.herokuapp.com/.

Media

The media team held a sprint in Berlin in December. Unfortunately none of these media improvements landed in Drupal 8.3, however we are very close to complete the base media functionality early in Drupal 8.4. There was significant progress on the visual media library too. Next step is to finalise the plugins for images, documents and oEmbed.

Join in the #drupal-media channel on IRC.

Migrate

The Migrate API became beta in Drupal 8.2.x with 8.2.5 and will apply to 8.3.0 as well. On the other hand other parts of the migration system like the Migrate Drupal API are still alpha stability and received some big updates. Two huge additions are the migration path for Drupal 7 node translations to Drupal 8 content translation and support added for configuration translations (and implemented initially for user profile fields).

Join in the #drupal-migrate channel on IRC.

Multilingual

Most of the recent progress on the multilingual initiative was in collaboration with the migration team and that is still heavily ongoing. Further feature development around multilingual features is not on the table currently, as most contributors moved on to more pressing areas given the advances achieved in multilingual with Drupal 8 already. Therefore it is being proposed to officially remove the multilingual initiative from the list.

PHPUnit

The work in the PHPUnit initiative is focusing on converting a large part of old Simpletest web tests to PHPUnit based browser tests. The goal is to commit a larger patch on February 21st to the Drupal 8.3.x branch. After that one third of Drupal core’s web tests would be converted to PHPUnit browser tests. We are also discussing the timeline for deprecating Simpletest.

We are also working on improving our JavaScript browser tests in multiple issues. For documentation there is also a Javascript browser test tutorial now!

If you want to convert your tests in your contrib / custom module, please read the PHPUnit browser test tutorial and help out on https://www.drupal.org/node/2794285 in case you run into problems. Please follow the PHPUnit initiative issue for status updates. Join us in IRC in #drupal-phpunit.

(This update written by klausi & dawehner)

Workflow

The biggest user facing change with workflows since the last update is the introduction of the Workflows module as a separate concept from content moderation. Now other modules can use workflows for user levels, commerce and other needs as well, when the workflow has nothing to do with content moderation. Many API changes were also made including support for moderation of non-translatable entity types and entity types without bundles (as long as revisions are enabled). Publishing entities implementing EntityPublishedInterface is also possible now, not just nodes.

Wondering how to join an initiative? Meeting information for each initiative is listed at https://groups.drupal.org/node/514585

Jan 16 2017
Jan 16

Drupal 8.0.0 replaced the earlier, in-place upgrade procedure for major version upgrades with a migration-based solution for core and contributed modules. Several modules serve this need in core: The Migrate module provides a general API for migrations, the Migrate Drupal module provides API support for Drupal-to-Drupal migrations, and the Migrate Drupal UI module offers a simple user interface to run migrations from older Drupal versions.

A lot of work has gone into making migrations more complete since the initial 8.0.0 release, including for multilingual sites with various configurations. Drupal-to-Drupal migrations are still not wholly complete (especially for Drupal 7 sources). However, lots of real-life use has validated the choices we made with the base Migrate API, and key architectural improvements have been completed already. An increasing number of contributed modules rely on it for their migrations.

Based on this stability and success, the Migrate subsystem maintainers and Drupal release managers have agreed the Migrate API (the Migrate module) now has beta stability! The change took effect in Drupal 8.2.x with 8.2.5 and will apply to 8.3.0 onwards as well.

What does this mean for sites and developers relying on the Migrate API?

Beta experimental modules are considered API- and feature-complete and beta modules are subject to the beta allowed changes policy. This means that module and migration developers can rely on the API remaining stable from now on! This also means that the focus with Migrate API is on fixing critical issues as well as bug fixes and contributed project blockers, if they are non-disruptive, or if the impact outweighs the disruption.

Note that Migrate Drupal and Migrate Drupal UI are still alpha stability, so API changes may still happen in these modules. Completing the Drupal-to-Drupal migration path and getting Migrate Drupal to beta stability is the next priority, so your help with missing and incomplete migrations is welcome!

If you want to get involved, the migration team is meeting every week at alternating times. The team has Google Hangouts at Wed 1pm UTC or Thu 1am UTC on an alternating weekly schedule. The #drupal-migrate IRC channel is also used as a backchannel.

Nov 18 2016
Nov 18

Would you guess that Drupal 8 is already one year old? One of my favorite changes with the Drupal 8.0.0 release was that we also chose to turn to scheduled releases (to happen twice a year) as well as semantic versioning (to allow us to make backwards compatible additions and improvements). That meant that we don't need to wait until Drupal 9 to come out with new exciting things, and indeed, there are various exciting initiatives going on in core right now. Maybe so many that they are hard to follow. So we decided to revive regular posts about core's progress so you can see what is going on and where you may be able to help. And this is not even all the things happening, just a sampling.

Default content

The latest incarnation of efforts to get default content into core was kicked off at DrupalCon Dublin. The plan is to create an experimental install profile that contains both a new front-end theme (a separate initiative see below) and example content. It was agreed in Dublin that the theme of the example content will follow the same ‘Farmers Market’ scenario as the Drupal user guide. This creates a lot of synergies and removes both continued argument over what the example content should contain and duplication of work involved in supporting more than one content scenario.

Join the ongoing work in this initiative on the weekly example content meetings happening on Google Hangouts on Air and join the #example-content channel in Drupal Slack. Lee Rowlands has created a sandbox project for the actual Drupal code. The content itself is being iterated on by Keith Jay and several members of his team.

Media

The plan for media management was just announced last week. We'll have a sprint in Berlin December 12-16 to kickstart development on some key parts of the initiative. Looking for funding for future sprints and sprinters to join the efforts as well. Help with adding a base entity form implementation to support revisions and implementing the file field redesign with drag and drop support would be helpful immediately though.

Multilingual

The multilingual initiative works closely with the migration team recently. The Drupal 7 to 8 core content translation migration is close to being committed and language negotiation settings and language types migrations for both Drupal 6 and Drupal 7 are close to landing as well. Would love to involve more people in migrating i18n and Entity translation module data.

New core theme

At DrupalCon New Orleans we kicked off an idea of adding a new theme to Drupal. To address some of the biggest concerns people had over the time about adding themes in core, we decided to work closely with the Default Content initiative.

Currently, the idea issue is in discussion, and before starting to do any further work, we are making sure we are on the same page regarding the key questions.

We created a Slack channel which you can join if you want to help or if you just want to follow our progress. Get an invite at https://drupaltwig-slack.herokuapp.com/.

PHPUnit

The PHPUnit initiative was born out of a Drupal 9 discussion what we need to get done before we will open a Drupal 9 Git branch. One goal is to modernize our automated testing system. We are currently using and maintaining a custom version of the Simpletest library which has served as well for many years. In parallel we adopted PHPUnit for our unit tests, but we realized that we can use PHPUnit as a general test runner for our functional tests as well. That means that we do not have to maintain as much test runner code ourselves as we do now.

The goal of the PHPUnit initiative is to move all our Simpletests to browser tests and in the end deprecate Simpletest in Drupal core. Another benefit of this initiative is testing real JavaScript interactions in our functional tests instead of fake AJAX requests performed currently in Simpletest.

You can help by converting AJAX tests to JavascriptTestBase for example. If you want to convert your test in your contrib / custom module, please read https://www.drupal.org/docs/8/phpunit/phpunit-browser-test-tutorial and help out on https://www.drupal.org/node/2794285 in case you run into problems. Please follow the PHPUnit initiative meta issue for status updates. Join us in IRC in #drupal-phpunit.

Workflow

The workflow initiative was one of the first approved initiatives after 8.0.0. The initiative is looking to improve the experience for content authors by improving content workflow and implementing other common patterns that editors are expecting. The plan is split up into multiple phases and in Drupal 8.2 the workflow initiative introduced Content Moderation as an experimental module. In Drupal 8.3 the initiative is planning multiple improvements, including the introduction of Trash module and possibly also components of the Workspace module.
One of the blocking issues that the initiative need help with reviewing is the upgrade between revisionable and non-revisionable entity storage. Any help on this will be much appreciated.

Stay tuned for further updates in December!

Nov 18 2016
Nov 18

Would you guess that Drupal 8 is already one year old? One of my favorite changes with the Drupal 8.0.0 release was that we also chose to turn to scheduled releases (to happen twice a year) as well as semantic versioning (to allow us to make backwards compatible additions and improvements). That meant that we don't need to wait until Drupal 9 to come out with new exciting things, and indeed, there are various exciting initiatives going on in core right now. Maybe so many that they are hard to follow. So we decided to revive regular posts about core's progress so you can see what is going on and where you may be able to help. And this is not even all the things happening, just a sampling.

Default content

The latest incarnation of efforts to get default content into core was kicked off at DrupalCon Dublin. The plan is to create an experimental install profile that contains both a new front-end theme (a separate initiative see below) and example content. It was agreed in Dublin that the theme of the example content will follow the same ‘Farmers Market’ scenario as the Drupal user guide. This creates a lot of synergies and removes both continued argument over what the example content should contain and duplication of work involved in supporting more than one content scenario.

Join the ongoing work in this initiative on the weekly example content meetings happening on Google Hangouts on Air and join the #example-content channel in Drupal Slack. Lee Rowlands has created a sandbox project for the actual Drupal code. The content itself is being iterated on by Keith Jay and several members of his team.

Media

The plan for media management was just announced last week. We'll have a sprint in Berlin December 12-16 to kickstart development on some key parts of the initiative. Looking for funding for future sprints and sprinters to join the efforts as well. Help with adding a base entity form implementation to support revisions and implementing the file field redesign with drag and drop support would be helpful immediately though.

Multilingual

The multilingual initiative works closely with the migration team recently. The Drupal 7 to 8 core content translation migration is close to being committed and language negotiation settings and language types migrations for both Drupal 6 and Drupal 7 are close to landing as well. Would love to involve more people in migrating i18n and Entity translation module data.

New core theme

At DrupalCon New Orleans we kicked off an idea of adding a new theme to Drupal. To address some of the biggest concerns people had over the time about adding themes in core, we decided to work closely with the Default Content initiative.

Currently, the idea issue is in discussion, and before starting to do any further work, we are making sure we are on the same page regarding the key questions.

We created a Slack channel which you can join if you want to help or if you just want to follow our progress. Get an invite at https://drupaltwig-slack.herokuapp.com/.

PHPUnit

The PHPUnit initiative was born out of a Drupal 9 discussion what we need to get done before we will open a Drupal 9 Git branch. One goal is to modernize our automated testing system. We are currently using and maintaining a custom version of the Simpletest library which has served as well for many years. In parallel we adopted PHPUnit for our unit tests, but we realized that we can use PHPUnit as a general test runner for our functional tests as well. That means that we do not have to maintain as much test runner code ourselves as we do now.

The goal of the PHPUnit initiative is to move all our Simpletests to browser tests and in the end deprecate Simpletest in Drupal core. Another benefit of this initiative is testing real JavaScript interactions in our functional tests instead of fake AJAX requests performed currently in Simpletest.

You can help by converting AJAX tests to JavascriptTestBase for example. If you want to convert your test in your contrib / custom module, please read https://www.drupal.org/docs/8/phpunit/phpunit-browser-test-tutorial and help out on https://www.drupal.org/node/2794285 in case you run into problems. Please follow the PHPUnit initiative meta issue for status updates. Join us in IRC in #drupal-phpunit.

Workflow

The workflow initiative was one of the first approved initiatives after 8.0.0. The initiative is looking to improve the experience for content authors by improving content workflow and implementing other common patterns that editors are expecting. The plan is split up into multiple phases and in Drupal 8.2 the workflow initiative introduced Content Moderation as an experimental module. In Drupal 8.3 the initiative is planning multiple improvements, including the introduction of Trash module and possibly also components of the Workspace module.
One of the blocking issues that the initiative need help with reviewing is the upgrade between revisionable and non-revisionable entity storage. Any help on this will be much appreciated.

Stay tuned for further updates in December!

Nov 17 2016
Nov 17

Last week Dries Buytaert published our plan for media management in Drupal 8 which details at least the immediate plans. The inherent limitation of file based attachment/image management in core is it does not mix well with remote media (Facebook embeds, videos, Digital Asset Management, etc.) and there is no library of media to browse to reuse existing media on the site. Therefore our short term goal is to add a base to support a wide varierty of media as well as a media library and support for embedding such media in posts in general.

To support this plan, we host online meetings every Wednesday at 2pm GMT in #drupal-media on IRC, but without focused time on implementing these, we are unlikely to succeed before the feature deadline of Drupal 8.3 at the end of January 2017. Therefore we are planning the following sprints for this year.

Dec 12-16 sprint in Berlin at Hubert Burda Media

Hubert Burda Media (initiators of the Thunder distribution) is hosting us at Potsdamer Straße 7, 10785 Berlin for a sprint between December 12-16. Confirmed attendees include (in alphabetical order) Adam Globus-Hoenich (phenaproxima), Christian Fritsch (chr.fritsch), Dietmar Gigler (dietmarg), Gábor Hojtsy, Janez Urevc (slashrsm), Marcos Cano Miranda (marcoscano), Mladen Todorovic (mtodor) and Samuel Mortenson (samuel.mortenson). Additionally Daniel Wehner (dawehner) and Florian Weber (webflo) plan to attend part of the sprint.

We'll work on bringing media features to core (not on contributed modules). If you'd like to get involved, participation in person or remotely would be amazing. This single sprint will not be enough to complete our goals. We are looking to figure out what is still possible in January and need funding to make things happen. If you can sponsor future sprints, reach out to Janez Urevc. This current sprint is funded by Hubert Burda Media, MD Systems, Acquia and Reinblau.Huge thanks to them!

Nov 25 sprint at DrupalIronCamp

DrupalIronCamp is Prague is also hosting four days of sprints. Janez Urevc (slashrsm) plans to sprint on the details of the media plan on Friday, November 25th. There may be other media related activities at the sprints, connect with the sprinters.

Nov 30 - Dec 2 sprint at DrupalCamp Munich

Hubert Burda Media also hosts the sprints before DrupalCamp Munich (sprints between November 30 - December 2, DrupalCamp on December 3-4). Several developers from Hubert Burda Media will sprint on both the core media goals and contributed modules. Look for Christian Fritsch (chr.fritsch) and Mladen Todorovic (mtodor).

Nov 17 2016
Nov 17

Last week Dries Buytaert published our plan for media management in Drupal 8 which details at least the immediate plans. The inherent limitation of file based attachment/image management in core is it does not mix well with remote media (Facebook embeds, videos, Digital Asset Management, etc.) and there is no library of media to browse to reuse existing media on the site. Therefore our short term goal is to add a base to support a wide varierty of media as well as a media library and support for embedding such media in posts in general.

To support this plan, we host online meetings every Wednesday at 2pm GMT in #drupal-media on IRC, but without focused time on implementing these, we are unlikely to succeed before the feature deadline of Drupal 8.3 at the end of January 2017. Therefore we are planning the following sprints for this year.

Dec 12-16 sprint in Berlin at Hubert Burda Media

Hubert Burda Media (initiators of the Thunder distribution) is hosting us at Potsdamer Straße 7, 10785 Berlin for a sprint between December 12-16. Confirmed attendees include (in alphabetical order) Adam Globus-Hoenich (phenaproxima), Christian Fritsch (chr.fritsch), Dietmar Gigler (dietmarg), Gábor Hojtsy, Janez Urevc (slashrsm), Marcos Cano Miranda (marcoscano), Mladen Todorovic (mtodor) and Samuel Mortenson (samuel.mortenson). Additionally Daniel Wehner (dawehner) and Florian Weber (webflo) plan to attend part of the sprint.

We'll work on bringing media features to core (not on contributed modules). If you'd like to get involved, participation in person or remotely would be amazing. This single sprint will not be enough to complete our goals. We are looking to figure out what is still possible in January and need funding to make things happen. If you can sponsor future sprints, reach out to Janez Urevc. This current sprint is funded by Hubert Burda Media, MD Systems, Acquia and Reinblau.Huge thanks to them!

Potsdamerplatz, Berlin
Photo of nearby Potsdamer Platz by Wolfgang Staudt

Nov 25 sprint at DrupalIronCamp

DrupalIronCamp is Prague is also hosting four days of sprints. Janez Urevc (slashrsm) plans to sprint on the details of the media plan on Friday, November 25th. There may be other media related activities at the sprints, connect with the sprinters.

Nov 30 - Dec 2 sprint at DrupalCamp Munich

Hubert Burda Media also hosts the sprints before DrupalCamp Munich (sprints between November 30 - December 2, DrupalCamp on December 3-4). Several developers from Hubert Burda Media will sprint on both the core media goals and contributed modules. Look for Christian Fritsch (chr.fritsch) and Mladen Todorovic (mtodor).

Oct 18 2016
Oct 18

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 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. (Last updated Nov 8th 2016).

  1. The JSON API and GraphQL meeting is held every Monday at 2pm UTC in the #drupal-wscii IRC channel.
  2. There is a monthly meeting on all API first work (REST, Waterwheel, JSON API, GraphQL) every third Monday of the month at 11am UTC in Google Hangouts.
  3. The Panels ecosystem meeting is on every Tuesday at 10am UTC in the #drupal-scotch IRC channel.
  4. There are two usability meetings every week! One at 7pm UTC on Tuesday while the other is at 7am UTC on Wednesday. Pick the best for your timezone. The meetings are at https://drupal.slack.com/archives/ux, get an invite at http://drupalslack.herokuapp.com/
  5. There is a default content in core meeting every other week on Tuesdays at 9pm UTC, and at 3pm UTC on the opposite weeks. Pick the best for your timezone. The meetings are at https://drupal.slack.com/archives/example-content, get an invite at http://drupalslack.herokuapp.com/
  6. There is a media meeting every Wednesday at 2pm UTC, join in the #drupal-media IRC channel.
  7. The multilingual meetings are still going on for years at 4pm UTC on Wednesdays, join at #drupal-i18n in IRC.
  8. The workflow initiative meets every Thursday at noon UTC in #drupal-contribute on IRC.
  9. Wanna help with migrate? The team has Google Hangouts at Wed 1pm UTC or Thu 1am UTC on an alternating weekly schedule. The #drupal-migrate IRC channel is also used as a backchannel.
  10. Last but not least the new user facing core theme initiative also meets on an alternating weekly schedule at Thu 2pm UTC and Thu 9pm UTC respectively in https://drupaltwig.slack.com/archives/new-core-theme-design, get an invite at https://drupaltwig-slack.herokuapp.com/

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

Oct 18 2016
Oct 18

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 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. (Last updated Nov 8th 2016).

  1. The JSON API and GraphQL meeting is held every Monday at 2pm UTC in the #drupal-wscii IRC channel.
  2. There is a monthly meeting on all API first work (REST, Waterwheel, JSON API, GraphQL) every third Monday of the month at 11am UTC in Google Hangouts.
  3. The Panels ecosystem meeting is on every Tuesday at 10am UTC in the #drupal-scotch IRC channel.
  4. There are two usability meetings every week! One at 7pm UTC on Tuesday while the other is at 7am UTC on Wednesday. Pick the best for your timezone. The meetings are at https://drupal.slack.com/archives/ux, get an invite at http://drupalslack.herokuapp.com/
  5. There is a default content in core meeting every other week on Tuesdays at 9pm UTC, and at 3pm UTC on the opposite weeks. Pick the best for your timezone. The meetings are at https://drupal.slack.com/archives/example-content, get an invite at http://drupalslack.herokuapp.com/
  6. There is a media meeting every Wednesday at 2pm UTC, join in the #drupal-media IRC channel.
  7. The multilingual meetings are still going on for years at 4pm UTC on Wednesdays, join at #drupal-i18n in IRC.
  8. The workflow initiative meets every Thursday at noon UTC in #drupal-contribute on IRC.
  9. Wanna help with migrate? The team has Google Hangouts at Wed 1pm UTC or Thu 1am UTC on an alternating weekly schedule. The #drupal-migrate IRC channel is also used as a backchannel.
  10. Last but not least the new user facing core theme initiative also meets on an alternating weekly schedule at Thu 2pm UTC and Thu 9pm UTC respectively in https://drupaltwig.slack.com/archives/new-core-theme-design, get an invite at https://drupaltwig-slack.herokuapp.com/

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

Oct 05 2016
Oct 05

Drupal 8.2 Available Now

Update: Drupal 8.2.1 is now available.

Drupal 8.2.0, the second 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.

What's new in Drupal 8.2.x?

This new version includes additional experimental modules to place blocks on pages, to edit configuration related to blocks without leaving the page, to create content moderation workflows, and to use date ranges. Several smaller authoring experience, site building, and REST and decoupled site improvements are included as well. (Experimental modules are provided with Drupal core for testing purposes, but are not yet fully supported.)

Download Drupal 8.2.0

Easier to place and configure blocks on pages

The new experimental Place Block module allows placing blocks on any page without having to navigate to the backend administration form. After selecting the region for placement, block configuration can be adjusted in a modal dialog allowing full control of all the details.

There is also a much easier way to modify block configuration, with the experimental Settings Tray module. Editing a block opens a tray in a sidebar with the block's title and other settings. For the site name block, for example, you can edit the site name directly in the sidebar. For menu blocks, you can adjust the menu there.

Drupal 8.2.0 Settings Tray module demonstration

Content moderation now included

Drupal has always supported both published and unpublished content, but more granular workflow support was not available in Drupal core. The new experimental Content Moderation module, based on the contributed Workbench Moderation project, allows defining content workflow states such as Draft, Archived, and Published, as well as which roles have the ability to move content between states.

Moderation states editor screen in Drupal 8.2.0

Support for date ranges

The Datetime module included with core only supports storing single points in time. The experimental Datetime Range module provides a new field type that also allows end dates. This is important for helping contributed modules like the Calendar module to work with Drupal 8 core.

Site building, content authoring, and administrative improvements

New content creation messagesDrupal 8.2.0 also improves stable functionality for administration, site building, and authoring. Drupal now enables revisions by default for new content types, to provide better accountability, to create a "safety net" for recovering from unintended changes, and to integrate with future workflow features. Content editors will enjoy a more seamless experience, as CKEditor's built-in dialogs are now styled to match Drupal-native dialogs, and creating any entity will always display a message linking to the new entity.

Other incremental enhancements include:

  • The user interface text has been improved on numerous administrative pages.
  • The redirection of site-wide contact forms is now configurable.
  • The comment view mode can now be selected in the display formatter form.
  • Relative URLs are converted to absolute ones in generated RSS feeds (ensuring that images and links work wherever the feeds are used).
  • Administrators can now elect to remove a module's content entities in order to uninstall the module.
  • The internal page cache has been improved for 404 responses.

Platform features for web services

The Drupal 8.2 release continues to expand Drupal's support for web services that benefit decoupled sites and applications, with bug fixes, simplified configuration, improved responses, and new features. It is now possible to read (GET) configuration entities like vocabularies and content types as REST resources, resolving a significant limitation for REST functionality in 8.1.x and earlier. Login, logout, and user registration are also now possible with REST. The authentication mechanism used by a REST Export Views Display is now configurable, and a cors.config service parameter was added for enabling and configuring cross-origin resource sharing (CORS). REST resource configuration is now also significantly simpler.

REST API demonstration

Developer API improvements

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

What does this mean to me?

Drupal 8 site owners

Update to 8.2.0 to continue receiving bug and security fixes. The next bugfix release, 8.2.1, is scheduled for November 2, 2016.

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

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 migration of multilingual functionality in particular is 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!

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.

The migration path from Drupal 7 to 8 is 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.)

Translation, module, and theme contributors

Minor releases like Drupal 8.2.0 are backwards-compatible, so modules, themes, and translations that support Drupal 8.1.x and Drupal 8.0.x will be compatible with 8.2.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.2.0 release candidate for more background information.

Oct 03 2016
Oct 03

Starting with Drupal 8, we decided to make more rapid innovation possible by releasing minor versions every 6 months that may come with new features and backwards compatible changes. Now that we released Drupal 8.1.0 and almost 8.2.0 as well, how did we do? Also what else is possible and what is blocking us to make those moves? What do all the changes mean for how might Drupal 9 unfold?

Dries Buytaert posted last Wednesday The transformation of Drupal 8 for continuous innovation and on the same day I presented Checking on Drupal 8's rapid innovation promises at DrupalCon Dublin. Here is a video recording of my session, which should be good for those looking to get to know Drupal's release process and schedule, as well as how we made it possible to experiment within Drupal core directly with Drupal 8. While I did hope for more discussion on the possibilities within Drupal 8 with the participants, somehow the discussion pretty much ended up focusing on Drupal 9, when it should be released and how much change should it come with.

[embedded content]
Sep 21 2016
Sep 21

As we are ramping up to work on significant user improvements for Drupal 8.3, one of the key areas of progress could be with media management user interfaces and features. For that to happen, we need to agree on what we are going to work on and then have people to implement it. The Media in Drupal 8 Initiative plan is being formed and is open for feedback now if having better core media support is near and dear to your heart. Please review and post feedback on the plan.

If you'd like to get involved with the implementation, you are more than welcome! The media team meets every Wednesday at 2pm GMT on IRC in #drupal-media.

Aug 29 2016
Aug 29

Start: 

2016-09-06 12:00 - 2016-09-09 23:55 UTC

Event type: 

Online meeting (eg. IRC meeting)

Drupal has adopted semantic versioning and a scheduled release cycle starting with Drupal 8.0.0. This means that it is possible within a major Drupal version to add new functionality in a backwards-compatible way, and there is no need to wait for Drupal 9 for improvements.

The second such version, Drupal 8.2.0, is going to be released on October 5th 2016, including the following new experimental modules: Content Moderation (to manage content review workflows), Outside-In (for editing configuration without leaving your frontend), Place Block (to add blocks directly to the page), and DateTime Range (to store end dates on date fields).

To prepare for Drupal 8.2.0, we released three beta versions in August. Announcements for beta1, beta2, and beta3 detail the significant changes made for Drupal 8.2.x. Now, we are getting ready to create Drupal 8.2.0-rc1, the first release candidate, the week of September 7, 2016.

This means several things in terms of support for Drupal 8.1.x versions and allowed patches in Drupal 8.2.x:

  • Starting with the RC, the 8.2.x branch will be subject to release candidate restrictions, with only critical fixes and certain other limited changes allowed.
  • To ensure a stable and timely release candidate, a commit freeze for the 8.2.x branch will begin Tuesday, September 6 at 1200 UTC.
  • The week of September 7 is also the final scheduled patch release window for 8.1.x, and it will not receive further development or support after that date aside from its final security release window on September 21 (which will not include bug fixes). Site owners and module or theme authors should prepare to update to 8.2.x.
  • As a consequence, all outstanding issues filed against 8.1.x will be automatically migrated to 8.2.x after the final 8.1.x patch release. Future bug reports should be targeted against the 8.2.x branch.
  • 8.3.x will remain open for new development during the 8.2.x release candidate phase.

See the Drupal core release cycle overview, Allowed changes during the Drupal 8 release cycle, and Drupal 8 backwards compatibility and internal API policy for more information.

Minor versions like Drupal 8.2.0 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.

Aug 24 2016
Aug 24

In my previous post I explained why there will be a Drupal 9 even though we have previously unseen possibilities to add new things within Drupal 8.x.y. Now I'd like to dispel another myth, that initiatives are only there to add those new things.

Drupal 8 introduced initiatives to the core development process with the intention that even core development became too big to follow, understand or really get involved with in general. However because there are key areas that people want to work in, it makes sense to set up focused groups to organize work in those areas and support each other in those smaller groups. So initiatives like Configuration Management, Views in Core, Web Services, Multilingual, etc. were set up and mostly worked well, not in small part because it is easier to devote yourself to improving web services capabilities or multilingual support as opposed to "make Drupal better". Too abstract goals are harder to sign up for, a team with a thousand people is harder to feel a member of.

Given the success of this approach, even after the release of Drupal 8.0.0, we continued using this model and there are now several groups of people working on making things happen in Drupal 8.x. Ongoing initiatives include API-first, Media, Migrate, Content Workflows and so on. Several of these are primarily working on fixing bugs and plugging holes. A significant part of Migrate and API-first work to date was about fixing bugs and implementing originally intended functionality for example.

The wonder of these initiatives is they are all groups of dedicated people who are really passionate about that topic. They not only have plan or meta issues linked in the roadmap but also have issue tags and have regular meeting times. The Drupal 8 core calendar is full of meetings happening almost every single workday (that said, somehow people prefer Wednesdays and avoid Fridays).

If you have an issue involving usability, a bug with a Drupal web service API, a missing migration feature and so on, your best choice is to bring it to the teams already focused on the topics. The number and diverse areas of teams already in place gives you a very good chance that whatever you are intending to work on is somehow related to one or more of them. And since no issue will get done by one person (you need a reviewer and a committer at minimum), your only way to get something resolved is to seek interested parties as soon as possible. Does it sound like you are demanding time from these folks unfairly? I don't think so. As long as you are genuinely interested to solve the problem at hand, you are in fact contributing to the team which is for the benefit of everyone. And who knows, maybe you quickly become an integral team member as well.

Thanks for contributing and happy team-match finding!

Ps. If your issue is no match for an existing team, the friendly folks at #drupal-contribute in IRC are also there to help.

Aug 18 2016
Aug 18

Drupal 8 introduced the use of Semantic Versioning, which practically means the use of three levels of version numbers. The current release is Drupal 8.1.8. While increments of the last number are done for bugfixes, the middle number is incremented when we add new features in a backwards compatible way. That allows us to add big new things to Drupal 8 while it is still compatible with all your themes and modules. We successfully added some new modules like BigPipe, Place Block, etc.

But how do we decide what will get in core? Should people come up with ideas, build them, and once they are done, they are either added in core or not? No. Looking for feedback at the end is a huge waste of time, because maybe the idea is not a good fit for core, or it clashes with another improvement in the works. But how would one go about getting feedback earlier?

We held two well attended core conversations at the last DrupalCon in New Orleans titled The potential in Drupal 8.x and how to realize it and Approaches for UX changes big and small both of which discussed a more agile approach to avoid wasting time.

The proposal is to separate the ideation and prototyping process from implementation. Within the implementation section the potential use of experimental modules helps with making the perfecting process more granular for modules. We are already actively using that approach for implementation. On the other hand the ideation process is still to be better defined. That is where we need your feedback now.

See https://www.drupal.org/node/2785735 for the issue to discuss this. Looking forward to your feedback there.

Aug 09 2016
Aug 09

Earlier this week Steve Burge posted the intriguingly titled There Will Never be a Drupal 9. While that sure makes you click on the article, it is not quite true.

Drupal 8.0.0 made several big changes but among the biggest is the adoption of semantic versioning with scheduled releases.

Scheduled releases were decided to happen around twice a year. And indeed, Drupal 8.1.0 was released on time, Drupal 8.2.0 is in beta and Drupal 8.3.x is already open for development and got some changes committed that Drupal 8.2.x will never have. So this works pretty well so far.

As for semantic versioning, that is not a Drupalism either, see http://semver.org/. It basically means that we have three levels of version numbers now with clearly defined roles. We increment the last number when we make backwards compatible bug fixes. We increment the middle number when we add new functionality in a backwards compatible way. We did that with 8.1.0 and are about to do it with 8.2.0 later this year. And we would increment the first number (go from 8.x.x to 9.0.0) when we make backwards incompatible changes.

So long as you are on some version of Drupal 8, things need to be backwards compatible, so we can just add new things. This still allows us to modernize APIs by extending an old one in a backwards compatible way or introducing a new modern API alongside an old one and deprecate (but not remove!) the old one. This means that after a while there may be multiple parallel APIs to send emails, create routes, migrate content, expose web services and so on, and it will be an increasingly bigger mess.

There must be a balance between increasing that mess in the interest of backwards compatibility and cleaning it up to make developer's lives easier, software faster, tests easier to write and faster to run and so on. Given that the new APIs deprecate the old ones, developers are informed about upcoming changes ahead of time, and should have plenty of time to adapt their modules, themes, distributions. There may even be changes that are not possible in Drupal 8 with parallel APIs, but we don't yet have an example of that.

After that Drupal 9 could just be about removing the bad old ways and keeping the good new ways of doing things and the first Drupal 9 release could be the same as the last Drupal 8 release with the cruft removed. What would make you move to Drupal 9 then? Well, new Drupal 8 improvements would stop happening and Drupal 9.1 will have new features again.

While this is not a policy set in stone, Dries Buytaert had this to say about the topic right after his DrupalCon Barcelona keynote in the Q&A almost a year ago:

[embedded content]

Read more about and discuss when Drupal 9 may be open at https://www.drupal.org/node/2608062

Jul 26 2016
Jul 26

There is about a week left before Drupal 8.2 goes into beta! That means we will switch to figuring out any issues with changes in the new version instead of making new changes. For core development that means new features and API additions will move up to 8.3. I asked initiative leaders of both proposed and active initiatives for key things that could use help in the remaining time.

API-first initiative

Allowing user registrations via the REST API only needs some more tests for which examples can be found elsewhere in core. Also, although it may sound a bit scary, REST requests without X-CSRF-Token header: unhelpful response significantly hinders DX, should receive a 401 response is actually a nice approachable novice issue to get involved with.

Ongoing, check out the proposed initiative roadmap and attend the API-first meetings every third Monday of every month 5pm GMT at in Google Hangouts.

Media initiative

An amazing feature is in the works to Improve the UX of Quick Editing images and could use some frontend reviews. Help is also welcome to get HTML 5 video and audio playback functionality directly from file field formatters as well as to get camera capture functionality on image fields.

Larger media management goals in core are still to be defined. The team is meeting on that on July 27th. Follow @DrupalMedia on Twitter. Public meeting times are 2pm UTC every Wednesday on #drupal-media on IRC.

Migrate initiative

Help on any of the issues tagged Migrate critical are welcome, especially Refactoring EntityFile to use process plugins instead which blocks several other issues.

Ongoing, check out the list of issues categorized in migrate's master spreadsheet, and follow @MigrateDrupal on Twitter. Public meeting times are alternating 1pm GMT Thursday and 1am GMT Friday every other week on Google Hangouts.

Workflow initiative

Content moderation module is proposed for core based on the existing improvements achieved by the initiative to expand revision handling for content. Helping with unblocking that issue is very welcome.

Other top issues are Allow removing a module's content entities prior to module uninstallation, Add archived base field to revisionable entities, and Upgrade path between revisionable / non-revisionable entities.

Ongoing, check out the high-level roadmap at https://www.drupal.org/node/2721129, and follow @drupaldeploy on Twitter. Public meeting times to be defined.

For a complete list of meeting times and places (links to Google Hangouts where needed), see the Drupal 8 core calendar.

Jul 20 2016
Jul 20

Drupal 8.2.0, the next planned minor release of Drupal 8, is scheduled for Wednesday, October 5, 2016. Minor releases include new features, usability improvements, and backwards-compatible API improvements. Here's what this means for core patches.

Drupal 8.2.0-beta1 will be released the week of August 3

  • In preparation for the minor release, Drupal 8.2.x will enter a beta phase the week of August 3.
  • Developers and site owners can begin testing the beta.
  • The 8.3.x branch of core will be created, and future feature and API additions will be targeted against that branch instead of 8.2.x.
  • All outstanding issues filed against 8.2.x will be automatically migrated to 8.3.x once it is opened.
  • During the beta phase, core issues will be committed according to the following policy:
    1. Most issues that are allowed for patch releases will be committed to all supported minor branches (8.1.x, 8.2.x, and 8.3.x) for the duration of the beta. Drupal 8.0.x is not supported anymore and changes are not made to that branch.
    2. Issues specific to added 8.2.x functionality, or disruptive changes that have a positive impact outweighing their disruption, will be committed to both 8.2.x and 8.3.x. (Such issues can be moved back to the 8.2.x branch after the automatic migration.)
    3. Most issues that are only allowed in minor releases will be committed to 8.3.x only.

Drupal 8.2.0-rc1 will be released September 7

  • The release candidate phase for the minor release begins on September 7, and starting on that date, the 8.2.x branch will be subject to release candidate restrictions, with only critical fixes and certain other limited changes allowed.
  • September 7 is also the final scheduled patch release window for 8.1.x, and it will not receive further development or support after that date aside from its final security release window on September 21.
  • All outstanding issues filed against 8.1.x will be automatically migrated to 8.2.x after the final 8.1.x patch release. Bug reports after September 7 should be targeted against the 8.2.x branch.
  • 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.3.x will remain open for new development during the 8.2.x release candidate phase.

See the Drupal core release cycle overview, Allowed changes during the Drupal 8 release cycle, and Drupal 8 backwards compatibility and internal API policy for more information.

As a reminder, we have until the start of the beta to add great new features to Drupal 8.2.x. Stabilizing experimental modules (such as Migrate and BigPipe), new features for workflows, and usability and bugfixes are all priorities for 8.2.0. Help with these feature requests and initiatives now for a great Drupal 8.2.0!

Jul 20 2016
Jul 20

There has been some amazing work on a User Guide for Drupal 8 for about a year now, and the English version is in pretty good shape -- it's in the stage now of copy editing and image refinement, and it will find its home under drupal.org/documentation. To start the translation process off, we need to figure out a translation workflow that will make sense for translation teams. It doesn't make sense to use the same workflow as is used on https://localize.drupal.org for the short strings that are part of Drupal and contributed modules, themes, and distributions (see https://www.drupal.org/node/2762261 for details) -- the guide is about 100 pages of formatted text prose, not a bunch of short strings.

We are looking for one or two teams initially to start using a proposed process for translation and provide honest feedback to improve the flow. This will help get the guide translated to as many languages as possible eventually.

More information and contact details at https://groups.drupal.org/node/512691

News tags: D8MI newsDrupal planetSite news

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