Contrib.social

Configuration change data loss prevention functionality inconsistent, restrictive

Open on Drupal.org →
Created on 10 January 2018, almost 7 years ago
Updated 26 October 2023, about 1 year ago

Problem/Motivation

Protection against accidental data loss is implemented inconsistently and makes it difficult and time consuming to make and deploy content model changes. Consider a few examples:

Via the Drupal UI...

Try to do deploy prohibited changes via configuration import and the whole operation will abort:

$ drush config-import -y
 Collection  Config                                         Operation
             core.entity_view_display.node.example.default  delete
             core.entity_view_display.node.example.teaser   delete
             core.entity_form_display.node.example.default  delete
             field.field.node.example.body                  delete
             field.field.node.example.field_example         delete
             node.type.example                              delete
[error] Import the listed configuration changes? (y/n): y
Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization. in Drupal\Core\Config\ConfigImporter->validate() (line 728 of
/var/www/example/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php).
[error] The import failed due for the following reasons:
Entities exist of type Content and Content type Example. These entities need to be deleted before importing.


The impact is that any project team tasked with significant or ongoing changes to the content model will spend a lot of time puzzling over inconsistent error messages, deleting content from local dev environments in order to make configuration changes, and writing update hooks in order to deploy them. The most skilled of teams will be slowed considerably. Junior teams are likely to get blocked.

Proposed resolution

  1. Settle on and consistently implement a pattern in the UI that...
    1. Warns when an action will cause data loss.
    2. Provides an option to accept the loss (e.g., "Delete all Example nodes and continue.").
  2. Provide an override for the ConfigImporter validation routine allowing configuration changes causing data loss to be imported so that Drush and other tools can use it.

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

🌱 Plan
Status

Active

Version

11.0 🔥

Component
Configuration  →

Last updated 4 days ago

Created by

🇺🇸United States traviscarden

Live updates comments and jobs are added and updated live.
  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

  • Needs usability review

    Used to alert the usability topic maintainer(s) that an issue significantly affects (or has the potential to affect) the usability of Drupal, and their signoff is needed. When adding this tag, make it easy to review the issue. Make sure the issue summary describes the problem and the proposed solution. Screenshots usually help a lot! To get sign-off on issues with the "Needs usability review" tag, post about them in the #ux channel on Drupal Slack, and/or attend a UX meeting to demo the patch and get direct feedback from designers/UX folks/product management on next steps. If an issue represents a significant new feature, UI change, or change to the general "user experience" of Drupal, use Needs product manager review instead. See the scope of responsibilities for product managers.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment about 1 year ago →
    🇬🇧United Kingdom catch

    The taxonomy module example shouldn't exist in its current state, it was ported from 7.x which was similarly broken. I opened 🐛 Deleting a vocabulary will fail when there are lots of terms Active to change it to match the content type example.

    Eventually, we could add batch/queue support for deleting unbounded numbers of the same entities, but until we have that, we shouldn't be attempting to load and delete potentially millions of entities within a form submission.

    I think this is more of a plan (that could have bug reports as child issues), but agreed it's a problem.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024