Drupal 10 compatibility

Please issue a D10 version

Please test: https://www.drupal.org/project/gtranslate/releases/8.x-2.x-dev →

Hi @edo88, thanks for doing work on this. We will test it out soon using our Drupal 10 sites and give you feedback.

One thing you should consider for this release is to make the transition away from the older "8.x-x.x" version number model and adopt the newer "Semantic Versioning" (semver) format. This would reflect a commitment to following Drupal development standards, and increase confidence in site owners considering adoption of your module.

Here is an explanation of the switch:

https://www.drupal.org/node/3108648 →

Here are some guidelines for module maintainers on making the switch to Semver:

https://www.drupal.org/node/1015226#semver-transition →

You are required to increment to a new major version number when you switch to semver, so this D10-compatible version would need to mark the transition to a 3.x branch.

I get a bad error in D10 with the dev-dev version composer require 'drupal/gtranslate:2.x-dev@dev'
php Error TypeError: array_values(): Argument #1 ($array) must be of type array, null given
in array_values() (line 385 of

@tjtj I encountered this same issue when upgrading from a 1.x version to the 3.0.1 version. I was able to resolve the issue by re-importing the config from the module:

drush cim --partial --source=modules/contrib/gtranslate/config/install

and then manually configuring it again. It looks like the config changed drastically but there was no update hook. The block is expecting some values that are addressed differently in the new vs old config and then crashing when it doesn't find them.

Hi,

Not sure why Drupal does not reimport default values during update, so re-install.

Thanks!

Not sure why Drupal does not reimport default values during update, so re-install.

This is not an accurate way to characterize the expected behavior of module that has been installed on a site. For a module that has been installed, it should not need to be uninstalled and reinstalled to receive configuration updates. Instead, Drupal provides the hook_update() API to manage this process.

It is the responsibility of the module maintainer to use this API, when introducing changes that affect the database schema, to modify the database for an existing installation to match what the newly installed module would provide.

It is best practice to map any user-configured settings from new to old values so that no user involvement is necessary for the update. A good example of this can be seen in the Google CSE module, which provides database updates for sites using version 3 moving to version 4:

- In the .install file, the module implements hook_update() and calls a database mapping function: https://git.drupalcode.org/project/google_cse/-/blob/4.x/google_cse.install

- That function finds the module's v3 configuration in an existing site and re-saves it for use with v4: https://git.drupalcode.org/project/google_cse/-/blob/4.x/google_cse.modu...

Automatically closed - issue fixed for 2 weeks with no activity.

@gravelpot is completely correct in #10, this issue should not be closed until there is a proper upgrade for the module implementing hook_update().

See 🐛 Errors after upgrading to 3.0.1 from 1.14 or 1.15 Needs work for the proper fix