Follow-up to #2374087: Create a persistent comment body field storage

We can now persist field storages. We should not create block_content body field storage in code since that means it is possible to deploy a field storage different from the type assumed in block_content_add_body_field(). It also means that contrib or custom modules can rely on the field storage being present. See #1426804: Allow field storages to be persisted when they have no fields.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alexpott’s picture

Status: Needs work » Needs review
FileSize
5.83 KB

I've move the basic block content type to the Standard profile since this is inline with the Node module and it will fail with this patch because it tries to create the body field before the storage exists. I think we should go the whole way in this issue and remove...

  /**
   * {@inheritdoc}
   */
  public function postSave(EntityStorageInterface $storage, $update = TRUE) {
    parent::postSave($storage, $update);

    if (!$update && !$this->isSyncing()) {
      block_content_add_body_field($this->id);
    }
  }

From the BlockContentType entity and put this functionality in the UI. We should try to avoid all side effects in configuration entities - especially those that create other configuration entities.

Status: Needs review » Needs work

The last submitted patch, 1: 2374125.1.patch, failed testing.

alexpott’s picture

Status: Needs work » Needs review
FileSize
10.01 KB
13.52 KB

We can stop adding body fields by default like so...

Status: Needs review » Needs work

The last submitted patch, 3: 2374125.3.patch, failed testing.

Berdir’s picture

Component: comment.module » custom_block.module

The component name is outdated, but comment is certainly not correct either ;)

alexpott’s picture

Status: Needs work » Needs review
FileSize
2.82 KB
16.34 KB

Thanks @Berdir.

Here's a patch the fixes all the tests. For me the only remaining question is should be introduce (or keep) some generic functionality somewhere to add the body field to block content type. And if the answer is yes - where?

Status: Needs review » Needs work

The last submitted patch, 6: 2374125.6.patch, failed testing.

alexpott’s picture

Status: Needs work » Needs review
FileSize
4.44 KB
19.08 KB

So it turns out migrate has a hard dependency on the basic block content type existing so we need to create one (and it's body field) through a migration. The migration tests are tricky but they caught this so huge++

Status: Needs review » Needs work

The last submitted patch, 8: 2374125.8.patch, failed testing.

alexpott’s picture

Status: Needs work » Needs review
FileSize
19.79 KB
2.45 KB

So I think the schema for migrate.source.empty is a bit tricky - we should just ignore the constants here - anything could be in there. This can be used to create anything migrate can create.

alexpott’s picture

larowlan’s picture

Assigned: Unassigned » larowlan

Putting on my list to review

yched’s picture

Looks like this needs a reroll - I reviewed on top of 55b8558.

  1. +++ b/core/modules/block_content/src/BlockContentTypeForm.php
    @@ -106,4 +109,36 @@ public function save(array $form, FormStateInterface $form_state) {
    +  protected function addBodyField(BlockContentTypeInterface $block_content_type) {
    

    So the three "body fields autocreated on 'bundle create' form submit" in core end up using three different patterns:
    - node body: a legacy node_add_body_field_function()
    - comment body: a public addBodyField() on CommentManager
    - block body: an internal helper method on the BlockContentTypeForm()
    That's a bit unfortunate ?

  2. +++ b/core/modules/config_translation/src/Tests/ConfigTranslationListUiTest.php
    @@ -389,6 +390,23 @@ public function doFieldListTest() {
    +    // Create a block content type.
    +    $block_content_type = entity_create('block_content_type', array(
    +      'id' => 'basic',
    +      'label' => 'Basic',
    +      'revision' => FALSE
    +    ));
    +    $block_content_type->save();
    +    $field = entity_create('field_config', array(
    +      // The field storage is guaranteed to exist because it is supplied by the
    +      // block_content module.
    +      'field_storage' => FieldStorageConfig::loadByName('block_content', 'body'),
    +      'bundle' => $block_content_type->id(),
    +      'label' => 'Body',
    +      'settings' => array('display_summary' => FALSE),
    +    ));
    +    $field->save();
    +
    

    Unless I'm missing smthg, looks like having a body field isn't actually needed for that test ?

alexpott’s picture

FileSize
6.19 KB
17.34 KB
  1. Yep you're right - reverted the removal of block_content_add_body_field() and used it everywhere. So now node and block_content are the same - and this set of related issues has not really changed anything wrt to the difference between them and comment.
  2. This test requires block_content to have a field - without this is does not have one.
yched’s picture

@alexpott: thnks - then aren't there tests modified here that could simply use block_content_add_body_field() instead of receiving new verbose code ?

Other than that, looks fine to me, but I'll let @larowlan review.

Status: Needs review » Needs work

The last submitted patch, 14: 2374125.14.patch, failed testing.

alexpott’s picture

Status: Needs work » Needs review
FileSize
2.02 KB
16 KB

Silly me. Didn't remove the the method on the form creating a body field.

alexpott’s picture

FileSize
15.99 KB

Rerolled - conflicted with #2346039: Add missing migrations to MigrateDrupal6Test and fix the result in core/modules/migrate_drupal/src/Tests/d6/MigrateDrupal6Test.php

larowlan’s picture

Status: Needs review » Reviewed & tested by the community

Can't see anything wrong with this - thanks!

catch’s picture

Status: Reviewed & tested by the community » Fixed

Looks fine.

Committed/pushed to 8.0.x, thanks!

  • catch committed b313cc6 on 8.0.x
    Issue #2374125 by alexpott: Create a persistent block_content body field...

Status: Fixed » Closed (fixed)

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