drush command default-content-export-module-with-references

+++ b/drush/default_content.drush.inc
@@ -41,7 +41,14 @@ function default_content_drush_command() {
+    'description' => dt('Exports all the content with theire referencs defined in a module info file.'),

here's some typos

Just corrected the typos

#4 works on latest dev.

When a module .info file marks an entity for export AND that same entity is detected as a reference by another entity, the result is that the entity gets exported twice in the same .json file, producing invalid syntax.

Steps to reproduce:
- Create 2 content types. #1 just has a title. #2 has a title and an entity reference field to #1.
- Create a node for each. In node 2, reference node 1.
- Create a module for use with default-content-export-module-with-references. Add the UUIDs of nodes 1 and 2 in this file. Export the content.

Result:
The JSON file for node 1 will contain duplicate output. There will be two top-level JSON tags, which is considered invalid syntax. Attempting to re-import the files will result in an error.

Updated patch in attachment. Sadly it conflicts with #2815051: Skip exporting core users by default.

Patch rerolled

+1 for this feature.
Should we also alert the user about new content that was exported?
Otherwise, how will we update the .info.yml file with the new UUIDs?

IMHO some level of test coverage would be super helpful.

+++ b/src/DefaultContentManager.php
@@ -270,7 +279,10 @@ class DefaultContentManager implements DefaultContentManagerInterface {
     foreach ($entities as $entity) {

@@ -295,6 +307,22 @@ class DefaultContentManager implements DefaultContentManagerInterface {
+  public function exportModuleWithReferences($module_name) {

This needs to go on the exporter now we've split the two. Needs a docblock too

And, yep - needs tests - could use vfsStream to simulate file system.

Here's a reroll.

Thanks, we just need a test now - nice work.

Would it make sense to fold this functionality into the dcer command, with a --module option?

Great, +1, but I got an error because there was still a reference to the manager service. Here's a fixed patch and interdiff.

> Would it make sense to fold this functionality into the dcer command, with a --module option?

+1 to that.

Also, this is going to need to be ported to Drush 9.

I've added the Drush 9 command.

> Would it make sense to fold this functionality into the dcer command, with a --module option?

Don't have the time to do that, I'm afraid, so will leave that for the next person who can push this forward a little!

2.0.x uses a completely different normalization implementation that does not depend on hal.module anymore.

Does this make this issue's progress up to #19 obsolete?

I've created a new drush command that works with 2.0.x

I've tested the latest merge request from justafish and it works great.

Hiding the files, which were for the 8.x-1.x branch.

The only issue I have is that I'd like to be able to define entity types not to export, e.g. the "user" entity. For example, if I export a block that has a media item, which has a file record and then a file, which all point to a user object, the command exports the block, media, file items and the file itself, but not the user. That said, the improvement could be done as a follow-up.

Merged, after rebasing to remove the .drush.inc changes (which is now removed).

Never used the module based exports myself, doing that with recipes in the future might be more useful, we'll see.