How & What We Need To Prepare For Drupal 9

If you are a site owner, install the Upgrade Status module. This module was built by Acquia. The module provides a graphical user interface on top of drupal-check. The goal is to provide an easy-to-use readiness assessment for your site's migration to Drupal 9.The next major version of Drupal is targeted to be released on June 3, 2020. Instead of building a radically new version of Drupal in a separate codebase, Drupal 9 is being built in Drupal 8. This means the upgrade experience will be smoother for core contributors, module authors, and site owners.

Drupal 9 will be a cleaned-up version of Drupal 8. It will be the same as the last Drupal 8 minor version with our own deprecated code removed and third-party dependencies updated. Drupal 9 was mostly already built in Drupal 8.

Instead of working on Drupal 9 in its own git branch from the start, we built most of Drupal 9 in Drupal 8. This has various benefits:

1. All new (Drupal 9 ready) code gets deployed on Drupal 8 sites before Drupal 9 is even released.
2. We can work out the issues in the new code in Drupal 8.
3. Feedback is provided based on this new code so it can be improved in Drupal 8.
4. This keeps us from refactoring too much like we did with previous Drupal versions, so we will not end up with an entirely reworked API.

The best user benefit is that the path of Drupal 8 to 9 is not a sudden jump. Instead, it is several smaller steps that are much easier to adopt.

Upgrading from Drupal 8 to Drupal 9 should be easy if you regularly check for and remove the use of deprecated code.

With Drupal 9 targeted to be released in June of 2020, many people are wondering what they need to do to prepare.

The good and important news is that upgrading from Drupal 8 to Drupal 9 should be really easy — radically easier than upgrading from Drupal 7 to Drupal 8.

The only caveat is that you need to manage "deprecated code" well.

If your site doesn't use deprecated code that is scheduled for removal in Drupal 9, your upgrade to Drupal 9 will be easy. In fact, it should be as easy as a minor version upgrade (like upgrading from Drupal 8.6 to Drupal 8.7).

Why Drupal.org deprecate

In Drupal 8, minor updates can introduce new APIs and features. When a new API is added, the old API will be deprecated in favor of the new one. We cannot remove the old API in a minor release because Drupal 8 makes a backwards compatibility promise, but it will usually be removed in the next major version (Drupal 9).

Contributed project developers, as well as those maintaining custom integrations, should follow the deprecations when possible and use the latest APIs available. This means that when Drupal 9 is released they will have to make fewer changes to be compatible.

What can be deprecate

• Methods
• Method parameters
• Procedural functions
• Return values
• Services
• Hooks
• Code paths & behavior
• Classes
• Plugins
• Files containing procedural functions
• Unintended behavior
• Internal APIs
• Asset Libraries
• JavaScript

What we can not deprecate

Do not deprecate test classes. Any test that could be considered deprecated should be removed or modified to be relevant.

Tests which exercise deprecated code can be annotated with @group legacy in order to avoid deprecation notices during testing, but a follow-up issue should be filed in order to fix such tests to not exercise deprecated code.

How do I know if my site uses deprecated code?

There are a few ways to check if your site is using deprecated code.

If you work on a Drupal site as a developer, run drupal-check. Matt Glaman (Centarro) developed a static PHP analysis tool called drupal-check, which you can run against your codebase to check for deprecated code. I recommend running drupal-check in an automated fashion as part of your development workflow.

If you are a site owner, install the Upgrade Status module. This module was built by Acquia. The module provides a graphical user interface on top of drupal-check. The goal is to provide an easy-to-use readiness assessment for your site's migration to Drupal 9.

If you maintain a project on Drupal.org, enable Drupal.org's testing infrastructure to detect the use of deprecated code. There are two complementary ways to do so: you can run a static deprecation analysis and/or configure your existing tests to fail when calling deprecated code. Both can be set up in your drupalci.yml configuration file.

If you find deprecated code in a contributed module used on your site, consider filing an issue in the module's issue queue on Drupal.org (after having checked no issue has been created yet). If you can, provide a patch to fix the deprecation and engage with the maintainer to get it committed.

How hard is it to update my code?

While there are some deprecations that require more detailed refactoring, many are a simple matter of search-and-replace.

You can check the API documentation for instructions on how to remedy the deprecation.

Why D9 Need?

How D9 Is Made?

How ready are the contributed modules?

Dwayne McDaniel (Pantheon) analyzed all 7,000 contributed module for Drupal 8 using drupal-check.

As it stands today, 44% of the modules have no deprecation warnings. The remaining 56% of the modules need to be updated, but the majority have less than three deprecation warnings.

Overriding Default Behavior

The drupalci.yml will look like a build.yml file, but with the codebase and environment phases omitted and having only the assessment phase. Drupal core ships with a drupalci.yml file that we can use as an example starting point. See https://cgit.drupalcode.org/drupal/tree/core/drupalci.yml

# This is the DrupalCI testbot build file for Drupal core.
# Learn to make one for your own drupal.org project:
# https://www.drupal.org/drupalorg/docs/drupal-ci/customizing-drupalci-testing
build:
  assessment:
    validate_codebase:
      phplint:
      csslint:
        halt-on-fail: false
      eslint:
        # A test must pass eslinting standards check in order to continue processing.
        halt-on-fail: true
      phpcs:
        # phpcs will use core's specified version of Coder.
        sniff-all-files: false
        halt-on-fail: false
    testing:
      # run_tests task is executed several times in order of performance speeds.
      # halt-on-fail can be set on the run_tests tasks in order to fail fast.
      # suppress-deprecations is false in order to be alerted to usages of
      # deprecated code.
      run_tests.phpunit:
        types: 'PHPUnit-Unit'
        testgroups: '--all'
        suppress-deprecations: false
        halt-on-fail: false
      run_tests.kernel:
        types: 'PHPUnit-Kernel'
        testgroups: '--all'
        suppress-deprecations: false
        halt-on-fail: false
      run_tests.simpletest:
         types: 'Simpletest'
         testgroups: '--all'
         suppress-deprecations: false
         halt-on-fail: false
      run_tests.functional:
        types: 'PHPUnit-Functional'
        testgroups: '--all'
        suppress-deprecations: false
        halt-on-fail: false
      # Functional JavaScript tests require a concurrency of 1 because there is
      # only one instance of PhantomJS on the testbot machine.
      run_tests.javascript:
        concurrency: 1
        types: 'PHPUnit-FunctionalJavascript'
        testgroups: '--all'
        suppress-deprecations: false
        halt-on-fail: false
      # Run nightwatch testing.
      # @see https://www.drupal.org/project/drupal/issues/2869825
      nightwatchjs:

Read More About It:

• https://www.drupal.org/drupalorg/docs/drupal-ci/customizing-drupalci-testing-for-projects
• https://dri.es/state-of-drupal-presentation-april-2019
• https://www.lullabot.com/podcasts/lullabot-podcast/drupal-9-webchick-gabor-catch
• https://dri.es/how-to-prepare-for-drupal-9
• https://www.drupal.org/docs/9

Thanks

Shamsher Alam