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
nginex β created an issue.
I provided a patch that extends logic of GenericContentEntity, so all base fields are taken into account with proper export and import logic.
Do not forget to clear cache before testing.
After a second look I decided to refactor a bit of new event, so it's more logical to be used + updated readme
For user entity I would definitely try to find a user by username if no match by uuid.
The issue is that user entity should have a unique username and if user A was create on site A and the same user was manually created on site B, they do have different uuid but the same username
Thanks for your contribution
Thanks for the patch, I fixed DI warning, looks good now!
I fully reworked the path and added global support for path field
Thanks for the patch!
I extended the logic a bit to work with any file schema not only private and public.
This is no longer needed, since 1.4.7 version all field types with simple get/set logic work out of the box
Thanks, it works!
nginex β created an issue.
Works like a charm!
Thanks for checking the issue!
All the references to your page will be also automatically exported, it's a recursive process and that's the way how the module works. If your content contains links or entity references to other content, that content will be also exported to keep references in place and up to date.
So you did nothing wrong ;)
Anyway, I'm planning to implement this issue β¨ Allow to partially export content Active , so it will be possible to export content without references
Can you check logs please?
did not know that block_id is a part of layout builder component, is it available out of the box in Drupal core or it's extra that is provided by some patch or contrib module?
nginex β created an issue.
Actually any field type should be automatically exported out of the box since 1.4.7
The simple field implementation will be removed since it's no longer needed. See π Clean up SimpleFieldDeriver in favor to use GenericField Active
No way itβs not working out of the box in the latest module version, could you please check that?
nginex β created an issue.
nginex β created an issue.
nginex β created an issue.
nginex β created an issue.
nginex β created an issue.
updated my original comment #25, thanks for the suggestion @fabianfiorotto