The configuration API in Drupal 8 and 9 provides a central place for storing configuration data. This is the place where modules and themes can store their data. So, for example, if a module has the settings form, the submitted form values are stored in the configuration. In the image below you can see the Redirect module's settings form and the config data for the form.
Regular site visitors and basic content editors on your site don't generate or use the configuration API. That is reserved only for developers and in some cases for site builders and/or themers. And while developing a site, module or a theme, developers sometimes need to delete certain configuration items. There are several ways to do that. Since contact forms in Drupal 8 are also configuration items, I will use the personal contact form here as the example.
By the way, you can always find the config name if you visit the Configuration -> Development -> Configuration synchronization -> Export -> Single item page and find the config item that you want to delete. The name will be displayed beneath the text area. You should omit the extension .yml
So, here are the 4 ways to delete a configuration item in Drupal 8 and 9:
drush config-delete "contact.form.personal"
- Drupal console
drupal config:delete active "contact.form.personal"
- Devel module
Enable the Devel module, go to the /devel/php page and execute this:
- Config Delete module
And if you prefer a visual way to do this, you can use my Config Delete module. Install it and then go to the Configuration -> Development -> Configuration synchronization -> Delete, choose what you want to delete and press the Delete button. If you want to install the module, this is how you can do it:
composer require drupal/config_delete drush en config_delete -y
The configuration API in Drupal 8 and 9 is really great and you should use it in a proper way to ensure the stability and security of your website. You should never make configuration changes on a live site because you can break it. The site's configuration should always be changed on a local machine, then tested on a staging server, and only after making sure that everything works fine, it should be deployed to a live site.
To prevent configuration modification you can check out the Configuration Read-only module.