Problem/Motivation

Received the following errors when executing on Acquia

[07-Mar-2025 08:08:31 Australia/Brisbane] PHP Fatal error:  Aborting! The New Relic imposed maximum PHP function nesting level of '5000' has been reached. This limit is to prevent the PHP execution from catastrophically running out of C-stack frames. If you think this limit is too small, adjust the value of the setting newrelic.special.max_nesting_level in the newrelic.ini file, and restart php. Please file a ticket at https://support.newrelic.com if you need further assistance.  in /mnt/www/html/app/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php on line 343 request_id="v-859eac34-fad7-11ef-ab17-a7262ac72245"

[07-Mar-2025 09:40:47 Australia/Brisbane] PHP Fatal error:  Allowed memory size of 135266304 bytes exhausted (tried to allocate 12288 bytes) in /mnt/www/html/app/docroot/core/modules/system/src/Plugin/ImageToolkit/GDToolkit.php on line 273 request_id="v-6d8c349c-fae4-11ef-a0b9-ef69445b1a82"

Steps to reproduce

Export nide with many dependencies.

Proposed resolution

Possible solutions

  • Offload recursion early
  • set limits in config
  • provide better debugging e.g. list of all node to be exported
CommentFileSizeAuthor
#24 issue-with-deeper-level-menu-3511539-24.patch.txt27.43 KBo_timoshchuk
#19 issue-with-deeper-level-menu-3511539-19.patch1.48 KBnpcoder
node-page-36e45032-cb0b-4114-9552-55db01505b1e_v1.4.7.yml35.64 MBlaureana
node-page-36e45032-cb0b-4114-9552-55db01505b1e_v1.4.6.yml225.19 KBlaureana
#13 Screenshot 2025-03-09 at 12.40.50.png175.43 KBnginex

Issue fork single_content_sync-3511539

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

vladimiraus created an issue. See original summary.

vladimiraus’s picture

vladimiraus
Primary language English
Location Brisbane 🇦🇺
commented

Digging further, the module collects same entity multiple times so looks like it is cyclic until it runs out of memory or times out.

 array:2 [▼
  0 => "taxonomy_term"
  1 => "1336"
]
 array:2 [▼
  0 => "taxonomy_term"
  1 => "439"
]
 array:2 [▼
  0 => "taxonomy_term"
  1 => "1336"
]
 array:2 [▼
  0 => "taxonomy_term"
  1 => "439"
]
 array:2 [▼
  0 => "taxonomy_term"
  1 => "1336"
]
 array:2 [▼
  0 => "taxonomy_term"
  1 => "439"
]
 array:2 [▼
  0 => "taxonomy_term"
  1 => "1336"
]
 array:2 [▼
  0 => "taxonomy_term"
  1 => "439"
]
vladimiraus’s picture

vladimiraus
Primary language English
Location Brisbane 🇦🇺
commented
Version: 1.4.10 » 1.4.x-dev
Priority: Normal » Critical

After further investigation I found versions 1.4.7+ are unusable for complex websites with a lot of references.

The issues discovered:

  • Even if taxonomy terms are UNselected in config, the module still exports taxonomies
  • Taxonomies go into infinite loop, because of $this->exporter->doExportToArray($entity->get('parent')->entity) in Drupal\single_content_sync\Plugin\SingleContentSyncBaseFieldsProcessor\TaxonomyTerm::exportBaseValues()
  • Instead of single content it is now exports all the content linked with no mechanism to stop it so it can result in hundreds of nodes instead of one.
nginex’s picture

nginex commented
Assigned: Unassigned » nginex
Priority: Critical » Normal

that's not a critical issue, it's easy to fix, expect a new patch in a few minutes

nginex opened merge request !154

nginex’s picture

nginex commented

well I don't know what is your exact structure, so it's hard to test it for me as I can't reproduce it. In any case, I provided a MR that might improve the export. Do you export node with a taxonomy reference or you export a taxonomy entity itself? Please provide more details of your content structure, so I can replicate it at least. Also take a screenshot of your settings form or paste the content of single_content_sync.settings.yml here (you can remove any custom entities if you wish)

nginex’s picture

nginex commented
Assigned: nginex » Unassigned
Status: Active » Needs review
vladimiraus’s picture

vladimiraus
Primary language English
Location Brisbane 🇦🇺
commented
Status: Needs review » Needs work

Nope, getting

The website encountered an unexpected error. Try again later.

Error: Xdebug has detected a possible infinite loop, and aborted your script with a stack depth of '512' frames in Drupal\Core\TypedData\DataDefinition->getDataType() (line 54 of core/lib/Drupal/Core/TypedData/DataDefinition.php).
vladimiraus’s picture

vladimiraus
Primary language English
Location Brisbane 🇦🇺
commented
Priority: Normal » Critical
nginex’s picture

nginex commented
Priority: Critical » Normal
Status: Needs work » Postponed (maintainer needs more info)

I asked you a few questions and received 0 answers, can you please provide any information about your content structure. If the issue is not reproducible out of the box, this cannot be critical.

Please set up a clean Drupal, set up the necessary content structure and relationships between entities, try to reproduce and if it’s reproducible, post the steps how to reproduce it

vladimiraus’s picture

vladimiraus
Primary language English
Location Brisbane 🇦🇺
commented

Thanks @nginex. Production data is too complex to export.
Let me setup clear instance and try to replicate it.
From what I investigated, entities that are referenced in text fields are being exported as well (both taxonomies and nodes).

nginex’s picture

nginex commented
Assigned: Unassigned » nginex
Status: Postponed (maintainer needs more info) » Needs work

Correct, that feature did not exist in 1.4.6. Probably it makes sense to change the logic of export there. Let me update the patch and try to optimize that moment (instead of exporting full entity I will only export stub version of it)

nginex’s picture

nginex commented
Assigned: nginex » Unassigned
Status: Needs work » Needs review
StatusFileSize
new Screenshot 2025-03-09 at 12.40.50.png175.43 KB

I provided a few new options of exporting for menu links of content and embedded links from formatted text. By default it will be Stub mode instead of Full one. Also it's possible to select None.

Let me know if new patch works for you. Don't forget to run drush updb.

New export form options

talishk’s picture

talishk commented

Was able to export the zip with the patch suggested. However, currently unable to import zip with all assets - Bad Gateway

An AJAX HTTP error occurred.
HTTP Result Code: 502
Debugging information follows.
Path: /batch?id=6746686&op=do_nojs&op=do
StatusText: error
ResponseText:
502 Bad Gateway
502 Bad Gateway
nginx

My observation is that the function validateYamlFileContent() is causing Bad Gateway when trying to decode the YML file

$content = Yaml::decode($content); in /single_content_sync/src/ContentSyncHelper.php

If anybody has faced similar issue, please advise

nginex’s picture

nginex commented

would it be possible to share the file you exported? I would like to review it and see what's wrong with it.

laureana’s picture

laureana commented

I believe this is related to commit 72ae530b821671faf1db0931fead72a564a27d27 which was made to address issue #3491573.

Instead of just have "uri: 'entity:node/xxx'", now we also have the "linked_entity" property with all related content.

For example, i've a node type "page" with lots of paragraphs inside. Inside one of them i've a field "link" related to another node "page". Instead having only this relation with the id, now i've have all contents of the second page and.. if this second have another link, and maybe it's enabled to be inside a menu, i have also all menu parents content in the export.

However, it's not important have a link inside the first page, it occours also if the first page provide a menu item (menu_link property), so all parents are exported.

The same content exported with different version of single_content_sync module could have a very different yml file sizes:

  • v1.4.6 -> 227KB
  • v1.4.7 -> 36.529KB
  • v1.4.9 -> 37.046KB
  • v1.4.11 -> 41.669KB

In this scenario i tried to export a "page" and the export starting from 1.4.7 exports about 75 pages with all contents.
In the first level i have "base_fields" at row 5 of the .yml, inside it i have "menu_link" at row 14 and "moderation_state" at row 190888. So i have 190k rows of "other pages content". In the 1.4.6 version (exporting the same content) the "menu_link" property that starts at row 14, ends at row 3254 because there isn't "linked_entity" prop.

So it's difficult to import in some circumstances (or need long processing times triggering a bad gateway in many environments). Maybe adding "linked_entity" could be an optional option of the export.

Ps. I'm not telling that it's wrong, i'm telling that after "linked_entity" property maybe it could be difficult import contents

Hope it helps!

nginex’s picture

nginex commented
Assigned: Unassigned » nginex
Status: Needs review » Needs work

I agree with @laureana

I forgot to include optimization for link file and its embedded entities to the config form to make it stub or optional.

Will extend my patch

nginex’s picture

nginex commented
Assigned: nginex » Unassigned
Status: Needs work » Needs review

embedded_entities_export_mode should be now in use for Formatted text and Link plugins. I think using stub option is gonna solve a lot of issues

npcoder’s picture

npcoder commented
StatusFileSize
new issue-with-deeper-level-menu-3511539-19.patch1.48 KB

We had a similar issue when exporting a "Layout Components Page" node using the single_content_sync module (version 1.4.13) in Drupal 10.4.3. The issue arises due to recursive field exports triggered by enabling the "Provide a menu link" option, resulting in excessively large exports and performance issues. It happened when there is a deeper level of the menu.

For fixing this issue, there is a patch. Please test it and comment.

nginex’s picture

nginex commented

Patch from #19 does similar job to the patch from MR 154, but the patch from MR has an extra configuration that allows to configure it instead of hardcoding

alfattal’s picture

alfattal commented

I was having similar issue and the patch in MR !154 fixed this issue for me. 1+ for RTBC.

nginex’s picture

nginex commented
Status: Needs review » Reviewed & tested by the community

Nice, I'm going to include this to the next release

jannakha’s picture

jannakha commented

+1 to MR 154
import/export works on a node that references 46 other nodes
total length of the export file is 16716 lines!

thanks for MR!
please release!

o_timoshchuk’s picture

o_timoshchuk commented
StatusFileSize
new issue-with-deeper-level-menu-3511539-24.patch.txt27.43 KB

I created a patch from the merge request, and it works well for version 1.4.13

  • nginex committed 9fdf53ab on 1.4.x 
    Issue #3511539: Improve exporting taxonomy parent entity
nginex’s picture

nginex commented
Status: Reviewed & tested by the community » Fixed

This is now available in new release 1.4.14

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

jannakha’s picture

jannakha commented

thank you to all the contributors!!! 🍾 🥂

Status: Fixed » Closed (fixed)

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