🇦🇹Austria @kevin.pfeifer

The problem is related to https://www.drupal.org/project/drupal/issues/3103620 🐛 Dependency on config storage causes circular reference in service container Needs review
We applied the patch #62 from that core issue and now its working again. Seems like its related to the fact, that we have raven (sentry plugin) installed as well in combination with the domain module.

So.... no one else encountered this issue yet?

kevin.pfeifer → created an issue.

Can confirm, that this patch fixes the error which happens on `drush updb` in the `system_post_update_add_langcode_to_all_translatable_config` step.

We solved this problem with the latest version by

1. composer require 'drupal/media_library_theme_reset'
2. Manually uninstalling the module in the drupal backend
3. composer remove 'drupal/media_library_theme_reset'

would be nice if a drush updb hook would be added in the next patch release to do that automatically

@jomsy sorry, we haven't yet since we just stayed on Drupal 10.1 for now.

We run into a similar issue with the Domain 2.0.0-beta1 when upgrading from Drupal 10.1 to 10.2 but haven't found a solution yet.

Circular reference detected for service "domain.route_provider", path: "options_request_listener -> domain.route_provider -> cache_tags.invalidator -> plugin.manager.block -> logger.channel.default -> logger.factory -> logger.raven -> router -> router.no_access_checks"

For me it was easiest to just uninstall the module before the Drupal 10 Upgrade.

Is anyone already working on this?

I can also confirm that I run into this error after trying to upgrade my Drupal 9.5 instance to Drupal 10.2 with the path_redirect_import 2.0.8 module.

What is curious to me is the fact, that drush seems to require a different version of the migrate_tools than what is currently required by the 2.0 version of this module

-> % composer why drupal/migrate_tools       
drupal/path_redirect_import 2.0.8  requires  drupal/migrate_tools (^6.0.2) 
drush/drush                 12.4.3 conflicts drupal/migrate_tools (<= 5)   

I imagine this could be related to why this problem currently appear

We were able to fix this issue by using https://www.drupal.org/project/entity_update →

These fields appread for us after upgrading from Drupal 9 to 10.

Since drush entity-updates doesn't exist anymore how does one resolve that now?

As explained above we had our own Shortcode classes which overwrote/extended the __construct method of the ShortcodeBase class.

We had to adjust

public function __construct(array $configuration, $plugin_id, $plugin_definition, $cart_provider = NULL, EntityTypeManagerInterface $entity_type_manager = NULL) {
    parent::__construct($configuration, $plugin_id, $plugin_definition);

to

 public function __construct(array $configuration, $plugin_id, $plugin_definition, RendererInterface $renderer, $cart_provider = NULL, EntityTypeManagerInterface $entity_type_manager = NULL) {
    parent::__construct($configuration, $plugin_id, $plugin_definition, $renderer);

and adjust the create() method to

  public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) {
    return new static(
      $configuration,
      $plugin_id,
      $plugin_definition,
      $container->get('renderer'),
      \Drupal::moduleHandler()->moduleExists('commerce') ? $container->get('commerce_cart.cart_provider') : [],
      $container->get('entity_type.manager')
    );

The $container->get('renderer'), was added

Sorry for not reporting back to your #34 question.

Yes, you can skip it (not sure why you even would have a pattern then in that case)

In our case we have a product sync with an external database (which should be rather self explenatory so the title of the product results in the path alias)
But there is also the possibility to manually add products to the drupal website (which is of course stupid but still our customer requires it) therefore the path auth pattern was required so that the alias is also generated automatically for those manually added products.

In the end it was our fault to expect the path field from core and/or the path auto module to automatically handle path changes when doing

$entity = $this->node_storage->load($id);
$entity->set('path', array('alias' => '/produkte/somename', 'pathauto' => \Drupal\pathauto\PathautoState::SKIP));
if($entity->save()) {
  // some more logic
} else {
  
}

instead (for everyone else checking this) you have to do this

$path_alias_manager = \Drupal::entityTypeManager()->getStorage('path_alias');
$aliasObjects = $path_alias_manager->loadByProperties([
  'path'     => '/node/' . $entity->id(),
  'langcode' => 'de' // <== set your language here if you have translatable nodes/aliases
]);

if(!empty($aliasObjects)) {
  $lastElement = end($aliasObjects);
  foreach($aliasObjects as $alias_object) {

    if($alias_object === $lastElement) {
      $alias_object->alias = $value['alias'];
      $alias_object->save();
    } else {
      // Delete duplicate alias
      $alias_object->delete();
    }

  }
} else {
  // If no path alias are present create it "normally"
  $entity->set('path', ['alias' => '/produkte/something', 'pathauto' => \Drupal\pathauto\PathautoState::SKIP]);
}

kevin.pfeifer → created an issue.

We just updated algolia/algoliasearch-client-php from 3.3.2 to 3.4.0 and this error appears.

In the end, will a @hook_update_N()@ be included in the fix to remove existing duplicates?

We had multiple websites with millions of duplicate alias entries.
In the end we cleaned it up ourselfs and adjusted our sync scripts to delete duplicate aliases manually on each sync run.

Patch #119 can't be applied to Drupal 9.5.10

I also have a project with the drupal/shortcode module and the patch from #5 fixes the problem!

Thanks @mfb for taking care of this :D

kevin.pfeifer → created an issue.

kevin.pfeifer → created an issue.

2 Problems were present here:

1) The bootstrap theme only adds the data-toggle="dropdown" to the menu ID main due to the fact, that this only happens in themes/contrib/bootstrap4/templates/navigation/menu--main.htm.twig. But we had another menu ID so I copied that file to our child theme and renamed to file to match the correct menu ID

2) The Menu block positioned in the block layout needed to have the option Expand all menu items enabled.

Nothing to do with JS.

This is the only module which prevents my setup to be upgraded to D10! It would be really great to see a D10 release soon.