Problem/Motivation
Hey.
We work with different environments (local, dev, stage, prod) and have different solr-servers for each environment. To maintain the correct relation between environment and server we tried to override the server-property of each index within settings.php (different on each environment):
<?php
$config['search_api.index.plant_index']['server'] = 'dev';
?>
In the exported configuration the server is set to the production server.
Looking on /admin/config/search/search-api everything seems as expected: the indexes are grouped into the environment-specific server. But if you try to index items or search something, the production server is queried.
Debugging lead me to the parameter used in the routes of SearchAPI: every parameter used there ("search_api_server" and "search_api_index") are loaded by the AdminPathConfigEntityConverter which loads the entity without any overrides.
Proposed resolution
Add with_config_overrides: TRUE
to every route using the needed parameters.
Maybe this also fixes #2670372: Index settings do not synchronize across environments, I couldn't test this yet.
Comment | File | Size | Author |
---|---|---|---|
#2 | param_config_overrides-2690373-2.patch | 5.16 KB | stBorchert |
Comments
Comment #2
stBorchertPatching late at night is not always the best.
We do *not* want to load the overridden config while editing a server or an index. This would be bad.
On "delete" we need the override because of the pre-/post-delete hooks so we clear the correct index on the correct server.
Comment #3
borisson_I think this looks good.
Comment #4
Alumei CreditAttribution: Alumei commentedThis seems to address the same problems from #2684977: Config overrides are sometimes ignored. and #2682369: Fix problems with overridden config entities.
#2670372: Index settings do not synchronize across environments is not affected by this but also RTBC by now.
Comment #5
Alumei CreditAttribution: Alumei commentedComment #6
drunken monkeyAs Alumei correctly says, there are already two issues for this – one too many, probably. Please help solve this problem in either of the other ones, and please search for existing issues next time before creating a new one!