13

On Drupal 8.1 I keep running in those kind of messages when I try to activate a custom module or a custom feature that makes some modification to the basic page. (add fields).

It is really annoying...

Steps:

  • Clear database entirely
  • go to /install.php and choose Standard profile
  • Now that the site is running go to Extend
  • Select Feature - Basic page

Result:

Unable to install Feature - Basic Page, core.base_field_override.node.page.promote, core.entity_form_display.node.page.default, core.entity_view_display.node.page.default, core.entity_view_display.node.page.teaser, field.field.node.page.body, node.type.page already exist in active configuration.

Well yeah... that is what I want to do: Change those default settings!

Expexted:

Be able to install my feature that makes some modifications to the basic page.

My Feature

Here is my Feature create with the Features module

It basically adds two fields, banner_image and background_image to the basic page

Files:

config
    install
        core.base_field_override.node.page.changed.yml
        core.base_field_override.node.page.created.yml
        core.base_field_override.node.page.promote.yml
        core.base_field_override.node.page.status.yml
        core.base_field_override.node.page.sticky.yml
        core.base_field_override.node.page.title.yml
        core.base_field_override.node.page.uid.yml
        core.entity_form_display.node.page.default.yml
        core.entity_view_display.node.page.default.yml
        core.entity_view_display.node.page.teaser.yml
        field.field.node.page.body.yml
        field.field.node.page.field_banner_image.yml
        field.field.node.page.field_image.yml
        field.storage.node.field_banner_image.yml
        language.content_settings.node.page.yml
        node.type.page.yml
feature_basic_page.features.yml
feature_basic_page.info.yml

Why this simple thing is not supported? Is it a bug? What should I do to be able to use my feature?

  • 1
    Use drupal EasyInstall module which is used to remove active configurations – Karthikeyan Manivasagam Aug 24 '17 at 10:45
  • 1
    +1 interesting module - worth a look - thank you @KarthikeyanManivasagam – therobyouknow Sep 30 '18 at 22:02
20

With drush you can probably do

drush config-delete module_name.settings

to delete the configurations that complain

  • I also discovered during my epic battle against Drupal that you can move those configs in a optional/ folder to make it shut up. But I am not sure of all the implications... – Guillaume Bois May 26 '17 at 19:05
  • @GuillaumeBois : the implications are that these optionnal configurations would be ignored if already installed, or if dependencies are not met. So, it can lead to further problems if the configuration is necessary for the module to work. – Renrhaf Nov 29 '17 at 23:13
  • +1 thank you @GiorgosK (Part 1 of 2): I found this solution to work in my case: I had this error showing in the web browser for my dev site: Warning: in_array() expects parameter 2 to be array, null given in lightning_layout_block_alter() (line 91 of modules/contrib/lightning_layout/lightning_layout.module). after setting up my site code git source and database on another machine. – therobyouknow Sep 30 '18 at 22:01
  • (Part 2 of 2) So to solve it I attempted to uninstall lightning_layout and re-install it. drush pm-uninstall lightning_layout worked but then when I tried to re-install it with drush en lightning_layout I got this command line error "In PreExistingConfigException.php line 65: Configuration objects (field.storage.node.panelizer) provided by lightning_layout already exist in active configuration" So I used your solution thus: drush config-delete field.storage.node.panelizer and was then able to re-enable the module: drush en lightning_layout – therobyouknow Sep 30 '18 at 22:01
  • if you are not sure what "settings" do you have to delete, you should run "drush config-list" to get the exact name of the configuration – Valvert yesterday
3

This thing is not supported because a module may not replace a config entity that already exists with install config.

To add form and view mode configurations for an already existing node type, you have to implement this in code in hook_install().

Or you have to delete the node type first on your site, but then you also have to delete the content.

And no, this is not a bug, this is how it is defined to prevent loss of configuration.

  • This is very sad. In D7 this was possible (add fields to a basic page through a Feature). I still think it should be in D8 too. You say it is to prevent loss of configuration, but in reality, it simply adds configurations (fields, weight, label, etc.). Note that I also had this problem with my own custom modules. – Guillaume Bois Jul 25 '16 at 12:04
  • No, it doesn't just add. the view and form displays are shared across all fields of a single node type. what happens if two modules try to add that file, who's going to win? What happens about existing fields that already are on the page type? what if the basic node type exists but with different settings than in your field? The behavior scenarios like that is not defined. For a standalone feature, you're better off defining your own node type and to deploy this change on your own site, you don't need a feature module like in 7.x, you can just export the configuration and import it again. – Berdir Jul 25 '16 at 19:39
  • @berdir this is very interesting. So I am coming from this issue from trying to create a user profile feature that includes view and form notes. So are you saying this can't be done in features because the user content type will have already existed and the feature is trying to enable that? Is there some way to allow a feature to override this so that someone could enable a profile feature on an already existing site? – kaleemclarkson Mar 19 '17 at 18:13
  • @kaleemclarkson user is not a content type but an entity type. The only way to do it is what I described, you have to implement code in hook_install() of your feature module to set form and view display configuration. Or use the profile module and define your own profile type there. – Berdir Mar 19 '17 at 21:43
3

Found module, use Easy Install module to purge active configuration without using devel or drush. It works even if you have missed out the optional folder and enforced option in your module's configuration files (yml)

  • 1
    This is a fantastic option! I just used this today and it saved me so much time! – rtd1123 May 16 '18 at 18:38
2

I have same issue for pantheon site. I entered drush command

Pantheonsite: drush @pantheon.SITENAME.ENVNAME config-delete ERRORNAME

Localsite: drush config-delete ERRORNAME

it's work for me.

1

With drush en it works!

[profile_test]$ drush en feature_basic_page -y
The following extensions will be enabled: feature_basic_page
Do you really want to continue? (y/n): y    
feature_basic_page was enabled successfully.   [ok]

EDIT: there is a way better solution now, see: How do I remove a configuration object from the active configuration?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.