@edmoreta

I faced a similar scenario while downloading the translation I uploaded from a Drupal site (10.2.x), the Lingotek version we have is 4.1.2. Here are the steps I followed for that:

- Go to /admin/lingotek/manage/node

- Select an item from the node list

- Request language (e.g. Spanish) translation

The original node WYSIWYG text has characters like "<", ">", among others that don't need the encode function. It seems the issue is resolved by removing the html_entity_decode function from a couple of places. Here's the patch I used to fix the problem we experienced. Let me know your thoughts on it and if we need to create a new issue for it.

While upgrading a site to 10.2.x I started to experience the "Cannot read properties of undefined (reading 'colSpan')" JS error, here's the patch I created for that. I couldn't determine a test case to trigger the "tabledrag-has-colspan" on a table cell.

I can confirm that the changes from this commit did the trick for us on custom code

I haven't updated the asset_injector version, I need to stick to v2.17.0. I'm using a patch for that reason

you might need to update the variationcache version to 8.x-1.4 https://www.drupal.org/project/variationcache/releases/8.x-1.4 → and follow the release note instructions

VariationCache is now part of Drupal core 10.2 and up. This release keeps it working on D10.0 and D10.1 but also makes it so it does not collide with D10.2 and actually uses the core classes by virtue of class_alias().

Once you upgrade to Drupal 10.2 and none of your code still refers to the Drupal/variationcache namespace, it is safe and recommended to turn off and remove this module.

It turned out we also had left behind some rows in the following database tables

• group_content
• group_content_field_data

I ran some comparisons using the YML file to determine which rows I need to delete. The YML files for these content types have names like group.content_type.group_content_type_1123kl123lkzz.yml

If you have orphaned data you might find out which type or bundle rows need to be deleted based on the group content type config files you have.

Once you have determined the orphaned rows, you can run some database delete queries.

\Drupal::database()->delete('group_content')
    ->condition('type', 'group_content_type_1123kl123lkzz', '=')
    ->execute();

\Drupal::database()->delete('group_content_field_data')
    ->condition('type', 'group_content_type_1123kl123lkzz', '=')
    ->execute();

I confirmed this fixes the issue for Drupal core 10.2.x (10.2.6), patch applied on asset_injector v2.17.0 (no update for this module, so using patch instead)

I was able to figure out a similar error on hook_update_n 9203 - Update group_content DB table, fields and indexes.

There were orphaned database rows (non-existing group content type) on my case, it should be the same for you. Also, if you are willing to upgrade to Drupal 10.2.x make sure you are using the group 2.3.x branch. Here is the link for that dev branch https://www.drupal.org/project/group/releases/2.3.x-dev →

re-posting MR patch

added small validation to prevent errors

I confirm the patch works with Drupal 10.2.4 and entity_embed 1.5

any thoughts on my comment here 📌 Add minimal upgrade instructions (1.x to 2.x) to project page Active ?

I've experienced config problems while upgrading from 1.x to 2.x (from 8.x-1.9 to 2.0.0). The release notes of config_split lack of "migration" / "Upgrading from v1 to v2" steps.

I'd say the module maintainers need to keep the composer dependency [module dependency] for a while, the best thing you could have done is to uninstall/disable the Drupal module and not both things at once (1. uninstall it from Drupal. 2. remove it from composer [I think it's not set in composer but in the info.yml file as a module dependency]). The config_split module should have run the configuration updates first and then uninstall the config_filter module, it did the opposite due to the `composer require` need to upgrade the module in composer.

Probably config_split module needs to keep hook update 8001 as is and add a new hook_update (8004) to the 2.x branch where you assume the config_filter is installed and uninstall it for us, that would prevent unexpected loss of configurations.

could it be somehow related to Issue #3089151 🐛 TableDrag JS :first-of-type issues Needs work ?

While upgrading a site to 10.2.x I started to experience the "Cannot read properties of undefined (reading 'colSpan')" JS error on line 361 https://git.drupalcode.org/project/drupal/-/blob/10.2.x/core/misc/tabled...

      if (index > 0) {
        cell = cells.filter(`:nth-child(${index})`);
        if (cell[0].colSpan && cell[0].colSpan > 1) {
          // If this cell has a colspan, mark it so we can reduce the colspan.
          cell.addClass('tabledrag-has-colspan');
        } else {
          // Mark this cell so we can hide it.
          cell.addClass('tabledrag-hide');
        }
      }

it seems the code is not working properly or lacks validation. I couldn't determine a test case to trigger the "tabledrag-has-colspan" on a table cell.

Patch for 10.2.x branch

for 10.2.x use patch from #79

Patch for 10.2.x based on #129

Isn't it better to revert to what we had initially?

Removing the escape from the label has resolved the issue for me. Thanks!

Patch #4 fails to pass phpstan tests

PHP Fatal error:  Declaration of Drupal\cl_server\Asset\UnoptimizedAssetResolver::getCssAssets(Drupal\Core\Asset\AttachedAssetsInterface $assets, $optimize) must be compatible with Drupal\Core\Asset\AssetResolverInterface::getCssAssets(Drupal\Core\Asset\AttachedAssetsInterface $assets, $optimize, ?Drupal\Core\Language\LanguageInterface $language = null) in /var/www/html/web/modules/contrib/cl_server/src/Asset/UnoptimizedAssetResolver.php on line 44

Tests might fail and they will require extra work

#46 it's not working

Re-roll for `10.1.x` branch

Given there are a couple of deprecated warnings, here's a patch that includes the fix for the following Upgrade status warning
"Call to deprecated method prophesize() of class PHPUnit\Framework\TestCase: https://github.com/sebastianbergmann/phpunit/issues/4141 "

#3 has an approach that refactors the Base class. Let me know your thoughts about it

I'm not sure if we still need to refactor the SchemaMetatagTagsTestBase.php class

edmoreta → created an issue.

Fixed wrong approach

Fixed wrong jquery library naming

Additional changes for D10 compatibility

Experienced the same issue, it seems we just need to use the LoggerChannelFactoryInterface class instead of LoggerChannelFactory.