0

I have a custom entity in my module. During installation I am creating a bundle for this entity. Then in the config I have two entity view displays for this bundle. One of those displays is for the default view mode.

During installation I am getting dependency exception for these two displays. But if I import them manually via config import everything works just fine.

So I have moved these into the optional config for now. This causes another issue and that is the display for default mode for my entity bundle.

When a new bundle is created the display for default mode is automatically created. So since I now have the config as optional it will try to import it afterwards but the display for default mode already exists so it will do nothing. The only solution that comes to mind is putting the config for this display into code bude I'd rather not.

So the solution for the first issue causes the second issue. Therefore how can I fix that dependency issue?

I was thinking about removing the dependency on the bundle form the display config and putting dependency on the display into the bundle config but that would not work since display needs an existing bundle first.

Improve this question
6
  • Well, what dependency error exactly? Core stopped doing that automatic creating of the body field including display configuration when config is created and only does it in the UI. I'd strongly recommend to do the same.
    – Berdir
    Jul 30, 2015 at 20:08
  • I don't know. I am installing drush(whole profile, not just this module) and it does not say and there is nothing in watchdog. But I have all field storages defined in config as well and I am creating fields instances when a new bundle is created so if I think about it the issue might be that in bundle insert I attach "default" fields to it and since somewhere around this time the display for default mode is being created by Drupal but since I am using my own config for it it is used before the default one is created but the field instances are not in caches yet so it will throw this error.
    – user21641
    Jul 31, 2015 at 6:18
  • But even if it were true I'm not sure how to solve this since if I'd import my "default" display after, the uuid would not match and it would not get imported.
    – user21641
    Jul 31, 2015 at 6:18
  • And the error is for that second display too which is not "default".
    – user21641
    Jul 31, 2015 at 6:18
  • OK, so I have been able to find out that the missing dependencies are the field instances. I think the issue is caused by the order of execution. So create bundle -> create display -> attach fields instead of create bundle -> attach fields -> create display. I will try to remove the dependencies. Since the components are a simple array the configuration of the display should be preserved.
    – user21641
    Jul 31, 2015 at 7:10

2 Answers 2

Reset to default
1

No, removing the dependencies is not the solution.

As I said in my comment, automatically doing something when config is installed or imported is an anti-pattern that should be avoided when possible.

Just create all the config through config/install and don't trigger automatically creating displays through pre/post save hooks/methods and your problems should go away.

Improve this answer
1
  • That is not what I'm doing. Basically I have field storages, entity bundle, one view mode and two entity view displays(one custom and one for "default") defined in configuration files. When a new bundle is created I attach field instances to it. That is the only thing that is not done via config since it cannot be done any other way. So I am not doing anything when a config is being processed at all.
    – user21641
    Jul 31, 2015 at 9:43
0

The issue was that the display modes contained configuration and holded dependencies on fields that were not yet attached to the entity bundle. Hence the issue. I am attaching "default" set of fields to all bundles on my entity when a new bundle is created so I think the displays are being imported before the fields are attached and that is the cause of this. The solution, for me, is to configure the displays programmatically and not via config.

Improve this answer

Your Answer

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