Another small bug report:
On every n-th load of a page having a search_api based view (or view-expoed-filters-block), the following notice occurs:
Notice: Undefined index: label in search_api_views_views_data() (line 78 of ..../sites/all/modules/contrib/search_api/contrib/search_api_views/search_api_views.views.inc).
Does anybody else get or did get that notice?
What's its background / cause?
Has it been fixed (as many others in search_api) in dev in the last two weeks?
Is a quickfix (check for availability of resp. array index) enough or is there a bigger underlying problem?
cheers,
daniel
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 1081666_search_api_views__PHP_NOTICE_LABEL.patch | 585 bytes | danielnolde |
| #1 | search_api_views.tmp_debug.patch | 797 bytes | drunken monkey |
Comments
Comment #1
drunken monkeyI think this is caused by a buggy Entity API integration in some module. Are you using an index on any non-core entities? If you are still unsure of the cause, please apply the patch, wait for the error to trigger (or clear the Views cache, which should trigger the error on the next page with a view) and then post the additional message here.
The message will only show when the Views cache is rebuilt, by the way — that's why you don't receive it on each page request.
Comment #2
danielnolde commentedAhaaa, your code helped a lot:
OG seems to be the problem!
We use a node-based search_api index, some node types are og-enabled, others not.
Currently, we _could_ remove the og-provided fields from the index, however future version should include the possibility to search for content of a specific group (well, that could be another indes, possibly) - so if possible we'd like to keep those og-provided fields in.
One simple way to prevent these notices in search_api would be to include a fallback to $key, if $info['label'] is not present, see attached patch. If that doesn't break anything, let's commit it, since we now _know_ that some modules might produce such notices, and they are easily preventable. Or perhaps a watchdog-entry could be generated in case of an non existing label, but the notice should be prevented.
Comment #3
drunken monkeyYou're right, we should just prevent those notices. Committed, thanks.
You should probably create an issue in the OG module too, though.