Documentation: Audit code for Drupal 9 compatibility

Created on 7 Aug 2019  路  16Comments  路  Source: Islandora/documentation

Should we be periodically auditing our code to make sure that it is compatible with Drupal 9? There are a couple of contrib module to help with this, e.g.,

drupal

Most helpful comment

I've heard this project plugged at Drupalcon: https://github.com/palantirnet/drupal-rector, it supposedly automates fixing 42% of deprecations from 8 -> 9.
Acquia also made this interesting site that tracks module status with relation to D9: https://dev.acquia.com/drupal9/deprecation_status

The general process for updating from 8 -> 9 is:

  1. make sure environment is D9 ready such as drush v10+, php7.3+, mysql5.7.8+, etc (ie other db platforms)
  2. make sure your core drupal is up to date on 8 as possible (8.9.x for example - only 8.8 and 8.9 are currently supported upgrades to D9)
  3. update your contrib modules to the versions that support D9 (this will likely involve a little digging but starting with the upgrade_status module will help get you started)
  4. remove deprecations from custom projects (perhaps starting with drupal rector to get you started)
  5. update core to d9 via composer

Helpful presentation slides from Drupalcon: https://slides.com/gaborhojtsy/state-of-drupal-9

All 16 comments

is there movement towards D9 now?

Here's what I've come up with so far is needed for D9 migration (the list is not complete, but it's a start):

Modules that need new releases (unless we're willing to ship with alpha/dev versions as the defaults):
facets - 9 supported in latest dev release
flysystem - 9 supported in alpha release
matomo - 9 supported in latest dev release
migrate_plus - 9 supported in beta release
webform - 9 supported in alpha release
permissions_by_term (in islandora_defaults) - 9 supported in 3.1.0
context - 9 supported in latest dev release (https://www.drupal.org/project/context/releases/8.x-4.x-dev)

Other requirements:

  • update drush from v9 to v10
  • update php from 7.2 to 7.3
  • removing deprecations from the islandora code (including islandora itself, but also periferal projects like the oai-pmh and jwt modules)
  • updating module info files saying we support D9

I've heard this project plugged at Drupalcon: https://github.com/palantirnet/drupal-rector, it supposedly automates fixing 42% of deprecations from 8 -> 9.
Acquia also made this interesting site that tracks module status with relation to D9: https://dev.acquia.com/drupal9/deprecation_status

The general process for updating from 8 -> 9 is:

  1. make sure environment is D9 ready such as drush v10+, php7.3+, mysql5.7.8+, etc (ie other db platforms)
  2. make sure your core drupal is up to date on 8 as possible (8.9.x for example - only 8.8 and 8.9 are currently supported upgrades to D9)
  3. update your contrib modules to the versions that support D9 (this will likely involve a little digging but starting with the upgrade_status module will help get you started)
  4. remove deprecations from custom projects (perhaps starting with drupal rector to get you started)
  5. update core to d9 via composer

Helpful presentation slides from Drupalcon: https://slides.com/gaborhojtsy/state-of-drupal-9

I see JSON-LD has pending patches for 9.x automatically generated https://www.drupal.org/project/jsonld/issues/3140878

openseadragon depends on the libraries module which is d8 only
carapace depends on adaptivetheme which is d8 only

https://github.com/Islandora/openseadragon/blob/8.x-1.x/composer.json references drupal/libraries:dev-3.x which is https://www.drupal.org/project/libraries and if i'm reading that readme correctly, its for external libraries?

Though Drupal 8 core has introduced improved library management tools (libraries.yml and unified library loading) it still does not offer a solution for handling external library dependencies that may be shared across multiple extensions. As a result this remains the primary problem space for the Libraries API module.

although its possible we can find a different way. i'm not super familiar with the osd module

I don't know that we need the libraries module anymore since we shifted how it was installed a while ago. I would try removing it and see what happens.

i tried uninstalling it and it was very unhappy with me...so then i tried a derp-y approach of clearing out the module files and just leaving the info.yml and the empty module and OSD viewer works. so i think i just borked the part about uninstall the module (probably because i'm already in d9 - i think if i had done the uninstall in d8, removed dependency and removed composer.json line, it might be ok)

I'm very confused and lost... I am trying to install the OpenSeadragon module with composer on a fresh ISLE with D9 (an Isle with core islandora but no defaults, I messed that up I think) but it can't be satisfied. Possibly due to this libraries requirement, possibly something else? I'm sorry I don't understand composer enough to know where I'm allowed to poke to try to fix this, or if this is even something fixable.

@rosiel can you send what the incompatibilities are?

I'm sorry, I gave up and now stuff is blown away and will take a while to rebuild to get to that point. I was attempting to assemble the equilvalent of Islandora Defaults, but without Islandora Defaults. I was randomly using composer require on things, assuming from first principles composer knowledge that I could composer require our packages and they would work. Diego showed me that specifying the branch seems to work and from then I had openseadragon (supposedly, though when i tried to load the viewer it was dark with no content and told me I was getting HTTP 0 results, so I probably had other things going wrong).

In general, I'm sorry, I don't know what I'm doing, and these comments usually come from frustration that I don't know where I am or if things are working or not.

Was this page helpful?
0 / 5 - 0 ratings