Allow updating existing content (and don't reimport existing)

Hi ... thanks @justin2pin for this nice attempt,
BUT there are some issues on this.
First of all (light matter) the interdiff shouldn’t be named that way. It shouldn't be a .patch file (as it is not) but a .txt one
(@see the related documentation: https://www.drupal.org/documentation/git/interdiff)

Second, more important, the patch is not applying cleanly.
My git apply default_content-allow_update-3042504-2_0.patch answers with the following error/warning:

default_content-allow_update-3042504-2_0.patch:71: trailing whitespace.
<?php
default_content-allow_update-3042504-2_0.patch:72: trailing whitespace.

default_content-allow_update-3042504-2_0.patch:73: trailing whitespace.
namespace Drupal\default_content\Event;
default_content-allow_update-3042504-2_0.patch:74: trailing whitespace.

default_content-allow_update-3042504-2_0.patch:75: trailing whitespace.
use Symfony\Component\EventDispatcher\Event;
error: config/install/default_content.settings.yml: No such file or directory
error: patch failed: default_content.module:12
error: default_content.module: patch does not apply
error: patch failed: src/Event/DefaultContentEvents.php:6
error: src/Event/DefaultContentEvents.php: patch does not apply
error: src/Event/UpdateEvent.php: No such file or directory
error: patch failed: src/Importer.php:4
error: src/Importer.php: patch does not apply
error: patch failed: src/ImporterInterface.php:12
error: src/ImporterInterface.php: patch does not apply
error: patch failed: tests/src/Functional/DefaultContentTest.php:102
error: tests/src/Functional/DefaultContentTest.php: patch does not apply

Ok. Let's make all this more clear with a new correct patch that cleanly applies into the 8.x-1.0-alpha7 branch and that does the following:

- stays over and includes the enhancements of the following issue: Do not reimport existing entities, applying the changes of the #109 patch, but removing the incorrect creation of the default_content-dont-reimport-existing-entities-2698425-102.patch file (it is affected by);

- applies the specific enhancements of this specific issue, already described by @justin2pin in the comment #2

for sake of completeness, this issue patch is mentioned into its parent one here

Thanks for your work here folks, this request has come up before and for a number of reasons we've decided this is outside the scope we want from the module.

The main reason is conflict resolution, we want this module to remain focused on default content and leave content-staging to modules that are designed for that such as

- deploy
- entity_pilot
- so on

Happy if you want to keep patches re-rolled here if you have to apply them for your particular project.

I realise a hard 'no' isn't always the desired response, but we're very much on the same page as the sentiment in this post https://wimleers.com/article/simplicity-maintainability-cdn-module-drupal-8

mah! ... strange. This feature has mainly been introduced to just "update" default content on existing deploys, without having to remove it and re-inject ...
Of course wouldn't aim to compete with "deploy" module.
In our workflow it is working so well with the few enhancements of this issue that should definitely (IMO) be introduced into the module dev branch, & without (the need of) enabling workspaces scenarios (& overhead).

Mostly I don't understand why I should be stopped here and be invited (I would say even forced ...) towards the entity_pilot (only alternative), that seems even not relying on open-source logic (this is commercial! ...).

Not the best example of opensource collaboration.

IMO, a Drupal project/module maintainer (and even creator) shouldn't act as owner of it, but (well ...) just as a maintainer of it.
Still relying on "collaboration over competition", different approaches to similar tasks should be respected, if not even encouraged.
And the community needs should be satisfied (when possible), and not clipped.
But this is just just a thought of mine (that I try to put in practice on the few modules I maintain).

Ok, thanks .. at least will be able to rely on this issue patches for our simple&straight default_content staging workflow.

Simplicity? You mean as in: "too simple to be useful"?

Let's imagine some perfect workflow.
So you prepare an entity, export it, commit to the repository and then your teammate checks it out, yes? No. It doesn't work. If your teammate has an entity with the same *ID* (not UUID!) then the import process breaks on error. Done.

I just don't get: what was the idea behind exporting by UUID and then fallback to the local IDs during import, and that - in another database which by definition doesn't share the same ID poll?

Adding the issue which seems to be the way forward with this as far as I can see.

@larowlan I would like to politely disagree with your choice of closing this out as won't fix. There is definitely a use case where importing and re-importing default content multiple times makes sense. One example is during the QA process where we want a clean known slate to do QA against but still allow the QA team to alter/edit content as needed. Another example is when a staging site has begun adding non-scripted content (and thus we can't clear the whole environment) but we need to update some of the previously created default content in a scripted approach.

To be clear, I don't think this module should become something that supports fully featured content staging where content is moved from one environment to another. Instead we should focus on doing "content setup" where we implement features that help with the initial site creation workflow.

I agree with @CoderBrandon and the rest of the people that think this feature is a required one. IMHO, we are not discussing about an extra feature, it is comparable to the reverse gear on a car. My situation:

• a base module provides some default content in English
• another module transforms the site into monolingual but in other language, that is, the new language is the only available language after enabling it
• default contents need to overwritten with a translated version

At the end, I did something similar to what the Umami default content module does, create and process content programmatically on install. For a few nodes, it brings simplicity and full control, avoiding to have enabled the default_content module in production environment, that does not pretty much after the initial deployment.

I further underline/stress that this feature (and related #9 patch) is super useful in updating remote default content, and seems to work very well so far to us ... Definitely a must add-on to this module.