Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I have several node types with default Title and Body fields.
Search index with this fields was created.
Drush config export/import works greate but Body field can not be imported for search index if I use profile install. I have no errors during theme install, search_api.index.SOME_NAME.yml has Body field.
But after import, I have only Title field.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | export_field_base-2838586-7.patch | 3.58 KB | oeklesund |
Comments
Comment #2
drunken monkeyIt seems the index is installed before the body field is, is that possible? Does the index (in the profile) correctly specify its dependency on the body field? (If it does, I think Core's config management should automatically take care of importing this in the right order. Although maybe those are also defined in different modules, and the profile doesn't define the correct dependencies for those?)
Comment #3
kashandarash CreditAttribution: kashandarash at AnyforSoft, Drupal Ukraine Community commentedYes, index is installed before the body field.
When I moved config to theme optional folder it worked.
But first time I did not have an error about dependencies, during install it is just skipped the field it should not be like that.
Comment #4
drunken monkeyOK, so is the dependency actually listed in the exported config file of the profile you're installing?
In any case, this is either a bug in the profile (wrong dependencies for either the exported index config, or the module containing it) or in Drupal Core's config management.
It would only be a bug in our module if the correctly saved index wouldn't contain the body field in its dependencies. (In that case, please re-open.)
Also, please see the Status settings of issues handbook page: "Needs review" only applies if there is a patch. Otherwise, it's just "Active".
Comment #5
oeklesund CreditAttribution: oeklesund commentedI had a similar issue. Only the field base would get exported in the config, which is not enough. Attached is a patch with a potential fix.
Comment #6
oeklesund CreditAttribution: oeklesund commentedHere an upgraded version. The underlying problem is that search_api is exporting the field dependencies to base fields. During installation, even if the field are there, it might be that there are no instances for it, which will result in failure. So we need to create a dependency to the field instance instead of the field base.
Comment #8
oeklesund CreditAttribution: oeklesund commentedModified tests accordingly
Comment #9
oeklesund CreditAttribution: oeklesund commentedComment #10
drunken monkeyComment #12
drunken monkeyWith "field base" I guess you mean the field storage?
That's on purpose, see #2472917: Make index configuration depend on field storage not instances and #2541206: Consider field storage dependency removal on Index. So, just reverting that will only lead to regressions in other areas.
It is a tricky problem, though, I admit. That field storages and field instances are separate (yet closely intertwined) config entities really causes a lot of problems. (Very possibly it solves yet more problems – but still.)
I can't really think of a way to resolve all of those issues – either you use (or include) the field instances, in which case you have dependency problems when removing just one field instance, and also explicitly depend on the exact bundle names; or you use the field storages, potentially ending up with unresolved dependencies during installation.
I actually thought #2792277: Respect the "syncing" state when saving an entity might have fixed these problems – just don't perform any such checks during config syncing. But it seems that doesn't apply during profile install? Or are you using a module version older than Beta 3?
For installation profiles, though, I guess you still have the option of just adjusting the module dependencies? Or are the default configs installed in bulk after all modules in that case?