🇮🇳India @gokul.jayan

Applying the MR patch helps eliminate the warning message.

Hi @hktang
During the Drush deployment process, changes were made to the openid_connect.settings, and the new changes were overridden. Try resaving the module settings and then run drush cex.

Hi @hktang
I also encountered the same problem with alpha5. In my case, when I resaved the module settings, there were changes to the role mappings—specifically, the removal of all role mappings and their replacement with only the role_mapping key containing an empty array. I believe resaving the module settings should resolve the issue.

gokul.jayan → changed the visibility of the branch 3497559-user-role-cleared to hidden.

Update to alpha5, and there are configuration changes for the module settings that needs to be exported. After the export the configuration looks something like this.

_core:
  default_config_hash: NFnOZU6VCOfURCAR4-O3V7eMHTx2LNqnCmDKRSNjjns
always_save_userinfo: true
connect_existing_users: true
override_registration_settings: false
end_session_enabled: true
user_login_display: above
redirect_login: /user
redirect_logout: /
userinfo_mappings: {  }
role_mappings: {  }
 

I encountered the same problem, and re-saving the OpenID Connect settings resolved it for me.

gokul.jayan → changed the visibility of the branch cherry-pick-9c439cfc to hidden.

gokul.jayan → changed the visibility of the branch cherry-pick-9c439cfc to active.

gokul.jayan → changed the visibility of the branch cherry-pick-9c439cfc to hidden.

Hi, the issue was caused by a deprecated jQuery function. I’ve resolved it and created a merge request. Please review it.

gokul.jayan → made their first commit to this issue’s fork.

@joelsteidl →

Hi, The deprecation error is invoked because the id is passed to the set property in the Service alter function.

 public function alter(ContainerBuilder $container) {
    if ($container->hasDefinition('apitools.client_base')) {
      $definition = new ChildDefinition('apitools.client_base');
      $definition->setClass('Drupal\zoomapi\Plugin\ApiTools\Client')
        ->addArgument('zoomapi')
        ->setProperty('id', 'zoomapi.client');
      // Add the definition to the container.
      $container->setDefinition('zoomapi.client', $definition);
    }
  }

Updating the Field permission module to 1.3 solves the issue.

Hi @dcine,

For fixing the drush you can implement the vendor/bin to your $PATH using direnv. You can refer the article here. https://www.drupal.org/docs/develop/local-server-setup/linux-development-environments/set-up-a-local-development-drupal-0-6 →

For the migration part

1. Please make sure that the machine name of fields are same as the old site.
2. Check that manage display & manage form display is configured properly.
3. Try to migrate in order.

If everything fails then go for custom migration.

Hi @dcine,

For fixing the drush you can implement the vendor/bin to your $PATH using direnv. You can refer the article here. https://www.drupal.org/docs/develop/local-server-setup/linux-development-environments/set-up-a-local-development-drupal-0-6 →

For the migration part

1. Please make sure that the machine name of fields are same as the old site.
2. Check manage display & manage form display are configured properly.
3. Try to migrate in order.

If everything fails then go for custom migration.

Hi @dcine,

For fixing the drush you can implement the vendor/bin to your $PATH using direnv. You can refer the article here. https://www.drupal.org/docs/develop/local-server-setup/linux-development-environments/set-up-a-local-development-drupal-0-6 →

For the migration part

1. Please make sure that the machine name of fields are same as the old site.
2. Check manage display & manage form display are configured properly.
3. Try to migrate in order.

If everything fails then go for custom migration.

 Upgrading drupal/variationcache worked for me

gokul.jayan → created an issue.