1) create a search index, configure some fields
2) featurize it
3) add it to a separate install that was installed in different order so the fields in the database are not in the same order (assumption that this is causing it)
4) Enable search feature
Result: after fr, feature is not overridden. After cache clear, feature is. The diff shows the options[fields] key has the fields the same, but in a different order.
Proposed solution: sort the fields on update so they're always sorted alphabetically
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | 2150779-search_api-features_overriden-1.patch | 416 bytes | hefox |
Comments
Comment #1
hefox commentedComment #2
drunken monkeyI'm pretty sure this cannot be the cause as we compare the field settings with
_search_api_settings_equals(), which takes care to ignore the order of array keys. My guess would be that some field is multi-valued on one install on single-valued on the other. Otherwise, please try to debug why/where_search_api_settings_equals()fails and we can fix that.Comment #3
drunken monkeyComment #4
hefox commenteddon't have time to look into it atm, but figured add some response.
The patch, after a drush fu, fixed the issue with the ping ponging.
Before that, one one install the feature never got overridden. On another install (which was older/had different order things were created), it was overridden in the ->options['fields'] key, with different fields being in a different order, an order that looked quite random, e.g. not alaphabetical.
Question: when you made that comment, did you know how features determines if a feature is overridden? I'm really not sure wh search_api_settings_equals would effect this. To determine, features calls the default hook/alter than compares it to eval of the export render command, so if anything is in a different order it'll come off as overridden. that's why features tries to alphabetize anything it can (which has caused bugs for things where order matters). However, search api is using entity api which uses it's own export functionality that does not enforce an order, so individual items need to enforce an order.
Comment #5
drunken monkeyYes, sorry, didn't quite think it through, or rather I confused it with the index being marked for reindexing (which is also a problem I've heard before, but of course something quite different). This looks like it would only be a problem when re-saving the Fields form, which you should probably avoid anyways. However, if the bug is as easy to fix as this, we can of course work around it that way. (I guess this will be relevant for D8, too, anyways.)
So, just waiting a few days for other reviews and then I'll commit.
Thanks for the patch, and sorry for the confusion!
Comment #6
drunken monkeyCommitted.
Thanks again!