Problem/Motivation

This issue is follow up of a suggestion given in Delete dependent config entities that don't implement onDependencyRemoval() when a config entity is deleted.
The main motivation is that API for deletion of field should not be responsible for deletion of the field storage. It should do only what the API method says that it will do and nothing more.

Proposed resolution

The code responsible to delete the field storage when the last field is deleted will be moved in the UI.

CommentFileSizeAuthor
#15 2442757-field-delete-dependency-13-interdiff.txt4.54 KBberdir
#15 2442757-field-delete-dependency-13.patch9.73 KBberdir
#10 interdiff-2442757-6-10.txt1.02 KBlanchez
#10 field_storage_deletion-2442757-10.patch6.25 KBlanchez
#8 field_storage_deletion-2442757-6.patch6.29 KBboyan.borisov
#6 field_storage_deletion-2442757-5.patch5.16 KBboyan.borisov
#4 field_storage_deletion-2442757-4.patch2.27 KBboyan.borisov

Comments

boyan.borisov’s picture

boyan.borisov commented
Issue summary: View changes
boyan.borisov’s picture

boyan.borisov commented
Related issues: +#2416409: Delete dependent config entities that don't implement onDependencyRemoval() when a config entity is deleted
boyan.borisov’s picture

boyan.borisov commented
Issue summary: View changes
boyan.borisov’s picture

boyan.borisov commented
Status: Active » Needs review
StatusFileSize
new field_storage_deletion-2442757-4.patch2.27 KB

I've created a patch.

Status: Needs review » Needs work

The last submitted patch, 4: field_storage_deletion-2442757-4.patch, failed testing.

boyan.borisov’s picture

boyan.borisov commented
Status: Needs work » Needs review
StatusFileSize
new field_storage_deletion-2442757-5.patch5.16 KB

It seems that I've missed to update a few tests which check exactly what we are trying to change.

Status: Needs review » Needs work

The last submitted patch, 6: field_storage_deletion-2442757-5.patch, failed testing.

boyan.borisov’s picture

boyan.borisov commented
Status: Needs work » Needs review
StatusFileSize
new field_storage_deletion-2442757-6.patch6.29 KB

and one more try

swentel’s picture

swentel commented
Status: Needs review » Needs work 
  1. +++ b/core/modules/field_ui/src/Form/FieldConfigDeleteForm.php
@@ -61,6 +61,11 @@ public function submitForm(array &$form, FormStateInterface $form_state) {
+      // Delete the associated field storages if they are not used anymore and are

    exceeds 80 chars 

  2. +++ b/core/modules/field_ui/src/Form/FieldConfigDeleteForm.php
@@ -61,6 +61,11 @@ public function submitForm(array &$form, FormStateInterface $form_state) {
+      if (!$this->entity->deleted && !$this->entity->isUninstalling() && $field_storage->isDeletable()) {

    I think we can remove the '!$this->entity->isUninstalling()' part

lanchez’s picture

lanchez commented
Status: Needs work » Needs review
StatusFileSize
new field_storage_deletion-2442757-10.patch6.25 KB
new interdiff-2442757-6-10.txt1.02 KB

Made those alterations.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Priority: Normal » Critical

As discussed at the sprint at Barcelona, this is the critical part of #2468045: When deleting a content type field, users do not realize the related View also is deleted, we need this to be able to show if a field storage will be deleted, so that we can show that the view will be deleted.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Status: Needs review » Needs work
Issue tags: +Needs tests

The patch is a good start, but to actually make this work, we need tests for that behavior and more importantly, we need to be able to show the dependencies that will be affected by deleting the storage together with the field dependencies.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Assigned: Unassigned » Bojhan

Going to work on this.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Assigned: Bojhan » berdir

Sorry @Bojhan :)

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Status: Needs work » Needs review
StatusFileSize
new 2442757-field-delete-dependency-13.patch9.73 KB
new 2442757-field-delete-dependency-13-interdiff.txt4.54 KB

First part, this provides the UI dependency information in the UI.

Remaining steps:

1. Write tests for this, going to be a bit complicated I fear, I need a view or something else that depends on the storage, a number of combinations
2. It now shows the field itself as a dependency that will be deleted, which is correct for the storage, but we obviously know that. Going to try and hide that.

I think I also incorrectly merged one part but I think we are removing too many tests anyway.

Jaesin’s picture

Jaesin commented 
+++ b/core/lib/Drupal/Core/Config/Entity/ConfigDependencyDeleteFormTrait.php
@@ -53,8 +53,7 @@ protected function addDependencyListsToForm(array &$form, $type, array $names, C
-      '#collapsible' => TRUE,
-      '#collapsed' => TRUE,
+      '#open' => TRUE,

@Berdir++

yched’s picture

yched commented 
  1. +++ b/core/modules/field/src/Entity/FieldConfig.php
@@ -224,27 +224,6 @@ public static function postDelete(EntityStorageInterface $storage, array $fields
-
-    // If this is part of a configuration synchronization then the following
-    // configuration updates are not necessary.
-    $entity = reset($fields);
-    if ($entity->isSyncing()) {
-      return;
-    }
-
-    // Delete the associated field storages if they are not used anymore and are
-    // not persistent.
-    $storages_to_delete = array();
-    foreach ($fields as $field) {
-      $storage_definition = $field->getFieldStorageDefinition();
-      if (!$field->deleted && !$field->isUninstalling() && $storage_definition->isDeletable()) {
-        // Key by field UUID to avoid deleting the same storage twice.
-        $storages_to_delete[$storage_definition->uuid()] = $storage_definition;
-      }
-    }
-    if ($storages_to_delete) {
-      \Drupal::entityManager()->getStorage('field_storage_config')->delete($storages_to_delete);
-    }

+++ b/core/modules/field_ui/src/Form/FieldConfigDeleteForm.php
@@ -61,6 +78,11 @@ public function submitForm(array &$form, FormStateInterface $form_state) {
+      // Delete the associated field storages if they are not used anymore and
+      // are not persistent.
+      if (!$this->entity->deleted && $field_storage->isDeletable()) {
+        \Drupal::entityManager()->getStorage('field_storage_config')->delete(array($field_storage));
+      }

    So you said we could also leave the deletion at the API level rather than at the UI level ? If so, I'd rather be +1 on that ? 

  2. +++ b/core/modules/field_ui/src/Form/FieldConfigDeleteForm.php
@@ -47,6 +48,22 @@ public static function create(ContainerInterface $container) {
+    $config_names = [$entity->getConfigDependencyName()];

    Minor : should we leave that as a parent:: call ?

Status: Needs review » Needs work

The last submitted patch, 15: 2442757-field-delete-dependency-13.patch, failed testing.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Priority: Critical » Normal

Yes. Which is why I created a new issue: #2575605: Field delete form does not display configuration dependencies that will be updated/deleted

The last submitted patch, 15: 2442757-field-delete-dependency-13.patch, failed testing.

Bojhan’s picture

Bojhan commented

@Berdid Haha :) I was already wondering what the UI aspect here was.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

smustgrave commented
Status: Needs work » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

andypost’s picture

andypost
he/him
Primary language Russian
commented

the same time core (field ui) still has no UI to even know that there's any field's table and definition exists...
Moreover body field for node/comment is created automagically

andypost’s picture

andypost
he/him
Primary language Russian
commented
Status: Postponed (maintainer needs more info) » Needs work

Patch #15 is totally ok to convert to MR and add tests, it brings visibility at least

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.