🇺🇦Ukraine @nginex

Thanks for all the hard work, but I noticed that it was already done as part of 🐛 Recursion takes too much memory compared to earlier versions (1.4.6 or earlier) Active . So I'm closing this issue as duplicated

I improved patch in 🐛 Recursion takes too much memory compared to earlier versions (1.4.6 or earlier) Active , would be nice to test it

I think the main performance issue is in related node menu Link, embedded entities from formatted text, embedded entities from link fields.

The patch above should handle it for complex sites.

Hi @kevinhurley23

I have improved patch from 🐛 Recursion takes too much memory compared to earlier versions (1.4.6 or earlier) Active , can you give it another go?

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

I agree with @laureana

I forgot to include link to the config form to make it stub or optional.

Will extend my patch

Provided simple example

Hi @datawench,

If the relevant asset represents a file entity, you can load a file entity and export it with

$embed_entities[] = $this->exporter->doExportToArray($file);

then simply populate the field value with new embedded entities, so in results it looks like this.

$value = $event->getFieldValue();
$embed_entities = [];

foreach ($value as &$item) {
  // Find and fetch file from the text $item['value'].
  ...
  
  // Export file.
  $embed_entities[] = $this->exporter->doExportToArray($file);

  foreach ($embed_entities as $embed_entity) {
    $item['embed_entities'][] = $embed_entity;
  }
}

$event->setFieldValue($value);

If it's not a file entity, then pass file path to the private storage e.g.

$assets = $this->privateTempStore->get('export.assets') ?? [];
if (!in_array($filepath, $assets, TRUE)) {
  $assets[] = $filepath;
  $this->privateTempStore->set('export.assets', $assets);
}

where $this->privateTempStore is $container->get('single_content_sync.store')

The import will automatically handle it.

nginex → created an issue.

Created a new issue for 3.1.x version with the patch that helps https://www.drupal.org/project/stage_file_proxy/issues/3529745 🐛 Add support of ImageAPI Optimize WebP Active

nginex → created an issue.

1. Need rebase after latest changes from 2.1.x
2. We still need to keep existing selector in the code because it will be a breaking change for existing content.

For the button I used this selector

button[data-eucc-open]

Tested on multiple real projects, works as designed

Ensured that custom script loads before the main script from eu_cookie_compliance

nginex → created an issue.

That option is available in this issue https://www.drupal.org/project/single_content_sync/issues/3511539 🐛 Recursion takes too much memory compared to earlier versions (1.4.6 or earlier) Active

Thanks for reporting issue, I forgot to test it with VBO, going to check it and improve, stay tuned

Thanks for reporting this issue, I'm glad you noticed that that early

seems like I did not include all the changes I needed for 1.4.12, it should be fixed now in 1.4.13

@ashraf.hussain could you please upgrade the module and verify it?

@ashraf.hussain

The fix was merged and released as part of 1.4.11

Since 1.4.11 you no longer need to apply a patch for this as it's already a part of the module.

greggles → credited nginex → .

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

I linked a related issue, I will add one more case to the existing patch from that issue to use stub entity approach for link fields, so recursion does not go to deep. Ideally need to provide option how deep recursion can go (how many levels). The option needs to be available from UI export form and in the existing drush command

@datawench

your patch is totaly fine, I'm glad it works as expected now.

I just created a MR based on your patch but adjusted the condition a bit, so it better suits the existing code.

I will include this issue to the next release, it will not harm for sure ;)

Hello, thanks for posting a detail issue here, I think a new field type that the module provides "entity_reference_entity_modify" is not fully supported by the module, as all the referenced fields need to go through a custom plugin. Try adding "entity_reference_entity_modify" here https://git.drupalcode.org/project/single_content_sync/-/blob/1.4.x/src/...

Then the custom plugin that exports references will pick that up https://git.drupalcode.org/project/single_content_sync/-/blob/1.4.x/src/...

But probably it will need to be extended and adjusted. When I have some time I can try to make a patch unless you do it faster ;)

No problems, thanks for quick feedback, all good now.

@code-brighton thanks for giving a credit to yourself and not a person that created a patch, well done

Provided a solution for Drupal 10.2 and above in MR11. See https://www.drupal.org/node/3363700 →

nginex → made their first commit to this issue’s fork.

Hi @facine,

The patch was working fine, but your change ruined it https://git.drupalcode.org/project/entity_change_default_language/-/merg..., so it stopped working

Could you please revert your commit and create a new release? because latest release currently does not work

Looks good, thanks

Thanks for more info, I see your point, then it makes sense to make a patch

Hello,

File entity does not have path field, so I'm not sure if that is the case. Please let me know if your File entity have path field?

Going to include this to the release. Tested with old exported content and new one. It works like a charm. Any feedback is welcome

Provided rework, so now the logic is in one place, File plugin, FileAsset plugin now contains only the field-related logic. Backward compatibility has been provided.

I realized that FileAsset can be refactored, so we keep the same logic in a single place File.php processor. FileAsset needs to simply export file entity then. Created a new branch to handle it

Thanks for the patch, could you please change schema version to 9135 or so, in your patch it's 10400. For your information first number is a minimum drupal core version supported, the module still supports drupal 9, so it must start with 9

I feel like it's a duplicate issue

thanks, going to include this to the next release

@cobblestone.consulting do you use CKEditor 4 or 5?

Thanks for the changes, going to add this to the next release.

Have you tried https://www.drupal.org/project/single_content_sync/issues/3511539 🐛 Recursion takes too much memory compared to earlier versions (1.4.6 or earlier) Active ?

I have exactly the same issue as described in #20.

Turned out that when content moderation is enabled for a content type and there are multiple translations, the table node_field_data will list only published translations. This is a problem because nid relationship has extra condition to match the language

For me the solution was quite obvious

/**
 * Implements hook_views_data_alter().
 */
function example_views_data_alter(array &$data): void {
  // We need to remove this extra language field in order to make it work
  // with unpublished translations of moderated content that are not listed in
  // node_field_data table.
  if (isset($data['node_field_revision']['nid']['relationship']['extra'])) {
    unset($data['node_field_revision']['nid']['relationship']['extra']);
  }
}

In my case this does improve drupal dynamic caching and does not break the functionality.

nginex → created an issue.

don't see any blocker why not to add UnchangingCacheableDependencyTrait, so views can still have max-age -1

If it breaks things, please report it here

Unfortunately fork failed during creation, so I could not push or fetch from it (it says repo does not exists)

Here is a file patch.

nginex → created an issue.

code cleaning

Ahh, this is duplicate of ✨ Export images uploaded via CKEditor Active , I tested it and it works perfect

nginex → made their first commit to this issue’s fork.

I'm planning to create 1.4.11 during a week, so already merged a few issues

Thanks for the patch, I will check and test it when I get some time. Meanwhile you can also test similar issue but with different solution here

https://www.drupal.org/project/single_content_sync/issues/3511539#commen... 🐛 Recursion takes too much memory compared to earlier versions (1.4.6 or earlier) Active

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.

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)

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

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 mode details of your content structure, so I can replicate it at least

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

I think for now you can try to apply a patch from from this issue 🐛 Handle potential exceptions on batch content import Active

I was exporting and importing zip files over 500 mb, and didn’t have memory issues, maybe there is some kind of recursion issue that causes infinite loop.

In any case, there is an issue that will optimize export ✨ Allow to partially export content Active , still need to find time to develop it

Pushed correct fix, the error is gone.

That's not a solution. Now I can see

Deprecated function: str_starts_with(): Passing null to parameter #1 ($haystack) of type string is deprecated in _rocketship_blocks_title_preprocess_block()

Let me provide a correct solution

I've never seen that issue before, could you please try UI import and see if there are any errors

/admin/content/import

This seems to be related. I really want this feature for the module as this might be a nice addition in many cases.

I will think of exact approach yet, but as far as I see this is a duplicate. Feel free to change status if I'm wrong

Hello,

I just took some time to properly check the issue and I think it's getting outdated.

The import/export directory file schema is now configurable in this issue 🐛 Export/Import throwing ZipArchive::open(): Argument #1 ($filename) cannot be empty in ZipArchive->open() Active but honestly, there will no longer be any "real" files generated during export and import since the module will switch to a stream approach in next release (already implemented, just doing some extra testing).

I don't see much sense to introduce new hooks.

You can alter translations by using event subscriber. See ✨ Include translations to ExportEvent event, so user can alter translations too Active

So by doing this you say no to importing of any existing exported content that still use base64 approach.

I would add a backward compatibility of old method to import method

@aaronchristian

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

let me try to take a look closer

will change priority because the issue in only applicable for live env on Acquia Cloud Platform hosting.

The patch is ready.

I made export and import directory file schema configurable.

Steps to test:

1. Apply patch
2. Execute drush updb && drush cr
3. Visit /admin/config/content/single-content-sync and change import directory schema to Public files.
4. Test import content on live once you release this change to live env.

Can you just resave your settings form?

I don't see any issues here, you config is just outdated or broken

@ashraf.hussain

I will try to provide a patch today, so it takes into account whole flow

I'm going to make it configurable

nginex → changed the visibility of the branch 3336041-breadcrumbs-not-corrent to hidden.

rerolled against 2.0.x, need to change target branch of MR to 2.0.x

nginex → made their first commit to this issue’s fork.

Unfortunately I don't have a project hosted on Acquia to test it.

Do you import the zip file via UI or drush?

If UI, maybe it worth trying to replace

'#upload_location' => "temporary://import/zip",

by

'#upload_location' => "public://import/zip",

Then the issue might gone

@ashraf.hussain what is your temporary file path on prod and other envs? is there a difference?

> 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

yeah, makes sense, feel free to extend existing configuration form

Hey @murz,

The [drupal_root]/scs-export is a fallback path if you don't mention the custom one.

e.g.

drush content:export node /relative/output/path

Patch works like a charm, thanks

bohart → credited nginex → .

I see, the module still supports php 7.4, and that syntax is available in php 8

I will create a separate issue to drop php 7 support in 2.x

what's your php version?

There are notes in MR that need to be taken into account