Drupal 11 compatibility

Working on it.

I've updated method signatures to align with upstream interfaces. But now I'm seeing:

InvalidArgumentException: Property entity is unknown. in Drupal\Core\TypedData\TypedDataManager->getPropertyInstance() (line 204 of core/lib/Drupal/Core/TypedData/TypedDataManager.php). Drupal\Core\TypedData\Plugin\DataType\Map->get() (Line: 50)
Drupal\content_sync\Normalizer\EntityReferenceFieldItemNormalizer->normalize() (Line: 152)
Symfony\Component\Serializer\Serializer->normalize() (Line: 24)
Drupal\serialization\Normalizer\ListNormalizer->normalize() (Line: 152)
Symfony\Component\Serializer\Serializer->normalize() (Line: 25)
Drupal\serialization\Normalizer\ContentEntityNormalizer->normalize() (Line: 92)
Drupal\content_sync\Normalizer\ContentEntityNormalizer->normalize() (Line: 148)
Drupal\content_sync\Normalizer\FileEntityNormalizer->normalize() (Line: 152)
Symfony\Component\Serializer\Serializer->normalize() (Line: 131)
Symfony\Component\Serializer\Serializer->serialize() (Line: 36)
Drupal\content_sync\Exporter\ContentExporter->exportEntity() (Line: 133)
Drupal\content_sync\Form\ContentExportForm->processContentExportFiles() (Line: 297)

As far as I can tell, here it's misinterpreting the "id" field (integer) as an entity reference field, and failing to load the referenced entity.

@star-szr pointed out that, in content_sync.services.yaml, the content_sync.normalizer.entity_reference_field_item service points to #2575761: Discuss a better system for discovering and selecting normalizers → . That ticket notes that:

[...] relying on the priority to just sort the services and pick the first match is very problematic. You need to get one weight wrong and everything explodes completely if you end up with a combination of normalizers or denormalizers that don't play nicely together.

We tried commenting out that service, and then see:

Call to undefined method Drupal\Core\Field\Plugin\Field\FieldType\IntegerItem::getUrl() in Drupal\content_sync\Normalizer\LinkItemNormalizer->normalize() (line 57 of modules/contrib/content_sync/src/Normalizer/LinkItemNormalizer.php). Symfony\Component\Serializer\Serializer->normalize() (Line: 24)
Drupal\serialization\Normalizer\ListNormalizer->normalize() (Line: 152)
Symfony\Component\Serializer\Serializer->normalize() (Line: 25)
Drupal\serialization\Normalizer\ContentEntityNormalizer->normalize() (Line: 92)
Drupal\content_sync\Normalizer\ContentEntityNormalizer->normalize() (Line: 148)
Drupal\content_sync\Normalizer\FileEntityNormalizer->normalize() (Line: 152)
Symfony\Component\Serializer\Serializer->normalize() (Line: 131)
Symfony\Component\Serializer\Serializer->serialize() (Line: 36)
Drupal\content_sync\Exporter\ContentExporter->exportEntity() (Line: 133)
Drupal\content_sync\Form\ContentExportForm->processContentExportFiles() (Line: 297)

Here's it's trying to use the LinkItemNormalizer on an IntergerItem.

This change record seems relevant for changes required for the normalizers: https://www.drupal.org/node/3359695 →

I implemented the change from $supportedInterfaceOrClass to ::getSupportedTypes() in Normalizer classes, with promising results.

The nature of the error has now changed:

Error: Undefined constant Drupal\Core\Database\Database::RETURN_AFFECTED in Drupal\content_sync\Content\ContentDatabaseStorage->cs_doWrite() (line 44 of modules/contrib/content_sync/src/Content/ContentDatabaseStorage.php). Drupal\content_sync\Content\ContentDatabaseStorage->cs_write() (Line: 149)
Drupal\content_sync\Form\ContentExportForm->processContentExportFiles() (Line: 297)

Looks like this is the relevant change record: https://www.drupal.org/node/3185520 →

Removing the deprecated 'return' query option resolved that issue and appeared to allow a bunch of exports, before running into:

Drupal\Core\File\Exception\InvalidStreamWrapperException:  in Drupal\Core\File\FileUrlGenerator->doGenerateString() (line 106 of core/lib/Drupal/Core/File/FileUrlGenerator.php). Drupal\Core\File\FileUrlGenerator->generateString() (Line: 32)
Drupal\file\ComputedFileUrl->getValue() (Line: 17)
Drupal\serialization\Normalizer\TypedDataNormalizer->normalize() (Line: 152)
Symfony\Component\Serializer\Serializer->normalize() (Line: 37)
Drupal\serialization\Normalizer\ComplexDataNormalizer->normalize() (Line: 152)
Symfony\Component\Serializer\Serializer->normalize() (Line: 24)
Drupal\serialization\Normalizer\ListNormalizer->normalize() (Line: 152)
Symfony\Component\Serializer\Serializer->normalize() (Line: 25)
Drupal\serialization\Normalizer\ContentEntityNormalizer->normalize() (Line: 92)
Drupal\content_sync\Normalizer\ContentEntityNormalizer->normalize() (Line: 151)
Drupal\content_sync\Normalizer\FileEntityNormalizer->normalize() (Line: 152)
Symfony\Component\Serializer\Serializer->normalize() (Line: 131)
Symfony\Component\Serializer\Serializer->serialize() (Line: 36)
Drupal\content_sync\Exporter\ContentExporter->exportEntity() (Line: 133)
Drupal\content_sync\Form\ContentExportForm->processContentExportFiles() (Line: 297)

@kul.pratap I believe when you commented that an issue fork with changes had already been started by @ergonlogic so this may not be the best issue to jump into since we are already actively working on it. I'm going to go ahead and unassign for now. Thank you for wanting to contribute!

Regarding the serializers, this old issue seems worth pointing out: #3255826: Leverage Core Serializers →

This latest issue appears to be due to an unconfigured private filesystem, which is the default in DDEV. Configuring it in settings.php allowed all of the files to be written:

$settings['file_private_path'] = '../private';

Perhaps it'd be worth adding a check for this setting in Drupal\serialization\Normalizer\ContentEntityNormalizer::normalize(), before trying to write to the private filesystem?

This allowed the batch process to complete, but then result in a WSOD:

TypeError: Drupal\Component\Utility\Html::escape(): Argument #1 ($text) must be of type string, null given, called in /var/www/html/.local-dev/web/core/lib/Drupal/Component/Render/FormattableMarkup.php on line 238 in Drupal\Component\Utility\Html::escape() (line 431 of core/lib/Drupal/Component/Utility/Html.php).
Drupal\Component\Render\FormattableMarkup::placeholderEscape() (Line: 187)
Drupal\Component\Render\FormattableMarkup::placeholderFormat() (Line: 195)
Drupal\Core\StringTranslation\TranslatableMarkup->render() (Line: 15)
Drupal\Core\StringTranslation\TranslatableMarkup->__toString()
strpos() (Line: 16)
Drupal\Core\Logger\LogMessageParser->parseMessagePlaceholders() (Line: 63)
Drupal\content_sync\Logger\ContentSyncLog->log() (Line: 127)
Drupal\Core\Logger\LoggerChannel->log() (Line: 50)
Drupal\Core\Logger\LoggerChannel->error() (Line: 276)
Drupal\content_sync\Form\ContentExportForm->finishContentExportBatch() (Line: 458)

That last error looks like a false positive. I had previously commented-out the initial snapshot taken in hook_install(). Re-enabling that and re-installing the module has resulted in a successful export.

The "Synchronize" tab no longer shows any deleted items, so that's encouraging too.

I guess testing importing would be the logical next step.