In #2127573: Stop creating node, comment and custom block fields automatically and provide defaults in CMI and #2127583: Stop creating administrator role actions programatically we explored providing default configuration this didn't work out. However these issue also included necessary code to not create configuration entities during an configuration sync which will still need to do.

During a configuration sync we should be automatically create an configuration entities as the result of creating another. At the moment this happens for blocks, roles and comments.

CommentFileSizeAuthor
#6 2148211.6.patch2.79 KBalexpott
#6 2-6-interdiff.txt654 bytesalexpott
#2 2148211.1.patch2.07 KBalexpott

Comments

alexpott’s picture

alexpott’s picture

Status: Active » Needs review
StatusFileSize
new2.07 KB

The relevant parts of those patches merged into one.

Status: Needs review » Needs work

The last submitted patch, 2: 2148211.1.patch, failed testing.

alexpott’s picture

Drupal\custom_block\Tests\CustomBlockTranslationUITest does not fail locally requesting a retest.

alexpott’s picture

Status: Needs work » Needs review

2: 2148211.1.patch queued for re-testing.

alexpott’s picture

Issue summary: View changes
StatusFileSize
new654 bytes
new2.79 KB

@swentel mentioned that the patch is missing the comment body field creation.

swentel’s picture

Status: Needs review » Reviewed & tested by the community

Good to go!

webchick’s picture

I'd like to commit this but I do not understand at all what's happening here. Maybe tests would help. But to me...

+++ b/core/modules/block/custom_block/lib/Drupal/custom_block/Entity/CustomBlockType.php
+++ b/core/modules/block/custom_block/lib/Drupal/custom_block/Entity/CustomBlockType.php
@@ -87,7 +87,9 @@ public function postSave(EntityStorageControllerInterface $storage_controller, $

@@ -87,7 +87,9 @@ public function postSave(EntityStorageControllerInterface $storage_controller, $
 
     if (!$update) {
       entity_invoke_bundle_hook('create', 'custom_block', $this->id());
-      custom_block_add_body_field($this->id);
+      if (!$this->isSyncing()) {
+        custom_block_add_body_field($this->id);
+      }
     }

postSave() is effectively a hook, acting just after the block is saved. Then if (!$update) is basically saying "if it's a new block.." So far so good. But if the block is actively synching, and custom_block_add_body_field($this->id) is skipped, when does the code go back and add it again? Does CMI re-issue a postSave() again once the block is imported?

swentel’s picture

@webchick

When config is importing, we want the actual configuration to be imported. In case someone created a block type without a body field on his dev site (ie, the user has removed the body field), and only kept an image field, we don't want to suddenly see a body field popping up on the production site because that's not what the user wanted.

We introduced this isSyncing flag in #2069373: Race conditions on import if CUD on ConfigEntity A triggers changes in ConfigEntity B which tests it for the body field on content types. I talked with Alex asking whether we need additional tests here too, but he argued that we'll tests this more thoroughly, to begin with in #2108813: Add fancier config import/export test scenario. So this is still good to go imo.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

All right, I still don't totally get it but let's give it a shot. :)

Committed and pushed to 8.x. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.