TypeError: Drupal\single_content_sync\ContentExporter::isReferenceCached()

I tested with both links and Entity embeds

Drupal core version 10.2.6
Entity embed 1.6.0
Single Content Sync 1.4.8

I was not able to reproduce this issue

Thanks for testing @borg_git

For some reason I'm still encountering this error, even outside of CKEditor.

Here's a menu link im trying to export.

@aaronchristian please clarify what version of the module you are using and what patches have been applied.
After all, this function "isReferenceCached" was added starting from version "1.4.8", and is located on line "123" of the file "TextField.php"

I can confirm this issue exists.
I've got the same issue on 1.4.10 (upgraded from 1.4.8 - which worked fine)
doesn't happen on all content types, I'm investigating which field causing the issue

I found why this issue is happening! (unfortunately, CKEditor is editable by users and they can copy paste things as they please)!

Steps to reproduce:

1. On a content node (article) insert into a text field's CKEditor source (a link to non-existent node):

<a href="/node/21991" target="_blank" data-entity-type="node" data-entity-uuid="30d77877-0000-0000-0000-14589bc25583" data-entity-substitution="canonical"><em><strong>HERE</strong></em></a>

2. Save node
3. Go to Export tab of this node
4. It will crash with same exception
TypeError: Drupal\single_content_sync\ContentExporter::isReferenceCached():

Proposed solutions:
- ignore invalid links, if $linked_entity is NULL don't try to add to $embed_entities
- report an error - link doesn't exist (so users will fix it and then do export)

Users are silly - they'll put all sorts of stuff into text fields, so

Thanks for looking into this one @jannakh.

I had a few patches applied previously so my errors line numbers might have been off, I removed them and started with a fresh install of 1.4.10 and am still noticing a failure on export. The patch seems to address import, and that works as expected, but on the export it fails.

I have a legacy site that has a lot of nodes with a number of paragraphs with links in each of them. When I uncomment lines 116-134 and run the export it actually processes the page and when it finally finishes loading I see it loads all the nodes and their fields, so my file for a single page was over 19MB!

I've attached a really basic file you can test with to reproduce the issue.

This is just menu_link_content, but for some reason it will load the whole referenced node and all its fields. Is it necessary to load all the embedded entities and their field values for links?

Thanks!

> This is just menu_link_content, but for some reason it will load the whole referenced node and all its fields. Is it necessary to load all the embedded entities and their field values for links?

at the moment it exports full entity if it was not exported yet, otherwise it will export base fields only. So in your generated file you should not see the same entity exported multiple times including all fields.

Anyway, I really want to improve this in ✨ Allow to partially export content Active to reduce size of generated files and just export what is really needed instead of everything

Hey guys, i was able to reproduce this issue with:

• Drupal: 10.4.2
• PHP version: 8.2.18
• single_content_sync: 1.4.10
• entity_reference_revisions: 8.x-1.12

also, the file @aaronchristian attached indeed import with no problem, but on export the issue happens.

So, after debugging i find out the issue was inside the exportCustomValues, and following the bug trail i realize the field entity_reference_revisions was unsupported, and when getFieldValue was called we'v got into a kind of loophole.

The solution i found was to check if the field has that specific unsupported type and then 'get the value as it is' as the previous code comment says.

igorgoncalves → closed merge request !149

@igorgoncalves

This worked really well, thanks for making this a priority this week my friend!

I tested this on all the various places I was able to crash the export previously and they all seem to work as expected.

I'll keep my eye on the "partial export" feature, I think that will be the game changer for this module.

Thanks for the exception module, its always been a HUGE pain point of Drupal, I'm glad there are people out there pushing initiatives like this through for the community.

I'll leave this one open for a bit for others to test with the supplied file I posted above, and then with the patch in place.

Looks good from my side, I would be happy to mark this one as RTBC in the next few days as I work through some more use cases.

Did a bit more testing, looks like some paragraphs don't get included on the export of one of my content blocks.

Lets take this one back as it looks like it needs a bit more work!

nginex → closed merge request !142

let me try to take a look closer

@aaronchristian

Could you please test a new patch I created in MR 152. Let me know if you still get errors during export.

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