Reworked the getEntitiesToExport function in the CommandHelper which should fix this issue
If I understand correctly, your configuration for the export is as follows (for example):
Custom block, media, custom menu link, content, taxonomy term -> These are allowed to be exported.
Then under Content, you have selected some sub types, for example "basic page"
And now, when you run drush content:export node or drush content:export --all-content, you are getting the error message.
Following the steps I outlined above, I was able to reproduce the error
Could you tell us what entity type you were trying to export? Perhaps a paste of your full command could provide us some insight
Thinking about the default export form, there could be some more changes to make it better.
Download button should export based on the configuration, not on what is currently selected on the form (label button accordingly).
Remove the extra form to select entity types/bundles to export all content from, but merge that functionality in the Default export form.
Add checks to exclude disallowed content from the default export if the settings form has changed after setting Default export settings. For example: Taxonomy terms are allowed to be exported in the module's settings. A taxonomy term has been added to the Default export settings form. Taxonomy terms are disallowed for export in the module's settings. Download from the default export settings form should now remove any Taxonomy terms from the default export (probably same for the drush command, or add appropriate warnings/error messages)
Hi @mlncn
The module has functionality to export / import custom entity types. From version 1.4.x you can use Plugins to support entity types that are not exportable by the module out of the box. If you need an earlier version of the module, you can use hooks for this. Please see the
documentation →
on how to do this.
There is also functionality to extend the export of supported entity types.
I agree, I have created a separate page for the Import on deploy ( Importing content on deploy → ) and also added the note about hooks deprecation to the upgrade path page
Moved Import content on deploy subject to a separate page Importing content on deploy →
The page order of the guide should be changed so that this page appears after the multiple export subject pages
@nginex I was unable to reproduce this, maybe could you provide that yml file, or steps to reproduce?
@nginex What cases is this issue referring to? I can see some ambiguity for 2 cases:
1. The entity is referenced in a Menu link, e.g. Main Navigation > node_to_export
2. The entity references a Menu link, e.g. node_to_export contains menu_link
I assume it's for the first case, but want to make sure
I have added documentation on how to extend the module with plugins on the following page: Exporting and importing custom entities and field types →
Added documentation for the new Plugin system as of 1.4.x. Deprecated hooks.
We have decided to go with the Drupal::root() approach after all. So this can be considered resolved after review.
Took another look at this.
I don't think we should be using the DRUPAL_ROOT approach for the outputpath. It should be using relative path as it was before. Rather than changing the result to a path from the DRUPAL_ROOT, it should be investigated how to make that relative path work for all users. It also doesn't make much sense to me to use DRUPAL_ROOT, as the fall back for a NULL in $this->requestStack->getCurrentRequest()->server->get('PWD') was already the default export location.
@Kuzmenko Thanks for your work on this.
I propose to also add an interface for the helper class.
Will need to investigate the DRUPAL_ROOT alternative to the $this->requestStack->getCurrentRequest()->server->get('PWD')
The hook you should be overriding is hook_content_export_entity_alter, by replacing "hook" to the name of the module that is implementing the hook, for example for the single content sync module, it would be single_content_sync_content_export_entity_alter. To implement the hook, the resulting function should be placed inside the .module file.
When you look at the hook in the single content sync module, you will see a switch that has a single case of 'my_custom_entity'. In your implementation of the hook that should be replaced with 'block_field', plus whatever else you need to alter to perform your export successfully, such as adding fields that should be exported from that content.
Thanks for the detailed report. It seems there have been changes to the ZipArchive in the newest PHP versions. Will take a look at it asap.
I like the idea of a form where a user can select several entities across entity types in order to perform one big export for all of the content that should be synced.
Default path and entities to export should also be possible.
I think this could be due to the change to how the configuration is treated in the install file. It used to be with strings, however, this was changed to array with ✨ Configuration by bundles Fixed .
@reece.oliver
An alternative approach for your issue might be to downsync your live database to your dev environment. In that case, the uuid's will match up, and then any changes exported from dev to live shouldn't be a problem.
Replacing uuid's is possible, but there is the issue of how to handle any references that the content may provide, as there might be duplicates if those are also using a different uuid.
Or there might be references to the wrong content, if there is a uuid that on the dev that is in use by some other content on the live environment.
Hi @reece.oliver
If I understand your request correctly, you want to be able to import content from an export into another entity that doesn't necessarily have the same entity id.
I can see the value in that, but this is is better moved to a separate issue, as it is not only related to the drush commands, but could also be a good general functionality to have in the ui too