To reproduce:

  • Add a few fields to the default account settings (admin/config/people/accounts/fields)
  • Take time to reorder the new fields in the form display (admin/config/people/accounts/form-display) and display (admin/config/people/accounts/display) panes (just make them visible)
  • Save the corresponding YML files (entity.form_display.user.user.default.yml and entity.view_display.user.user.default.yml at a minimum) anywhere on your disk
  • Create a dummy module
  • Add the saved files in the config dir of your new module
  • Add and install the module on a totally new site (which thus deploys your saved configuration)

Now, you should be having your default user account settings with the new fields but also with any form display / display options and ordering that've you come up with. Problem is the form display and display settings and ordering seem to be ignored (set to Disabled) when the module is enabled.


  • Copy over all YAML files in the active dir to the staging dir
  • In the staging dir, manually replace (overwrite) the YAML files that seem to have been ignored (entity.form_display.user.user.default.yml and entity.view_display.user.user.default.yml) when you enabled the module
  • Rely on CMI's sync feature (admin/config/development/configuration) to a) detect changes and b) overwrite the current active configuration
  • Now go back to your account setting's form display / display panes and confirm that your options and ordering is there as originally expected

I couldn't tell if #2030073: Config cannot be imported in order for dependencies has any impact on the above bug report but thought this would worth mentioning just in case.


anavarre’s picture

Issue summary: View changes
anavarre’s picture

With the latest HEAD today, I'm getting an import error with CMI sync because of different UUIDs. Modyfing the UUID so that it's identical to the corresponding current active file UUID fixes it.

EDIT: I did try to lure D8 by updating the mymodule/config/*.yml files with the expected UUIDs before enabling the module, in order to see if it would make any difference. Turns out it didn't and the problem is still the same.

swentel’s picture

Hmm, we've had a similar thing in #1986090: Profile config does not overwrite module default config on install (system.cron.yml) , might be the same problem.

Berdir’s picture

Status: Active » Closed (works as designed)

Modules are not allowed to overwrite existing active configuration, that now throws an exception.

view/form displays are special because they are a container for possibly many fields. If you just provide one, you need to use the API in hook_install() to set up your widget/formatter.