The OpenLayers module has a display type that removes all fields in the query function
From /openlayers/modules/openlayers_views/views/openlayers_views_style_map.inc
/**
* Query - override to make sure this doesn't get run
*/
function query() {
$this->view->query->fields = array();
$this->view->executed = TRUE;
}
Because search_api_views makes the $fields property protected, this call in OpenLayers fails. Quickly making the $fields public (in both query.inc files) fixes the issue, and now you can use OpenLayers to show Faceted filtered maps (which is pretty awesome).
I am not including a patch, because I see there is a few more protected properties that could possibly also be made public, but I cant say I would understand the implications of that.
The query.inc files I adapted are
/includes/query.inc
search_api/contrib/search_api_views/includes/query.inc
Comment | File | Size | Author |
---|---|---|---|
#19 | openlayers_revert-1340888-19.patch | 654 bytes | Shawn DeArmond |
#5 | openlayers-views-fix-query-fields-1340888-5.patch | 654 bytes | nod_ |
Comments
Comment #1
drunken monkeyThis file hasn't got anything to do with this, so definitely shouldn't be touched.
Otherwise, I think the OpenLayers module is to blame here. It just assumes that Views' default query plugin will be used for the query, which of course will lead to problems with other query plugins. (To be fair, Views itself does the same in a lot of places.)
Might be that making this property public seems to fix the error, but it really only conceals the bug, which consists of an illegal assumption.
The OpenLayers display plugin should just check which query plugin is used, or if there is an accessible
$fields
property on the query, and only set it to an empty array if appropriate.Moving this issue accordingly.
Comment #2
zzolo CreditAttribution: zzolo commentedHey @drunken monkey, do you have any tips on how to do this properly in a Views plugin?
Comment #3
zzolo CreditAttribution: zzolo commentedSome more detailed debugging information, that probably doesn't help too much, but just in case: #1341892: Ajax error when building view map over search index.
Comment #4
drunken monkeyI don't exactly know what you want to accomplish there, but checking whether
$this->view->query->fields
is accessible before modifying it should be sufficient.Comment #5
nod_Something like this ?
Maybe you could write a test for that ? i don't know how to reproduce so i can't be sure it fixes the issue.
Comment #6
nod_Comment #7
batje CreditAttribution: batje commentedI applied this patch and it worked for me.
Comment #8
zzolo CreditAttribution: zzolo commentedSome more data: #1365564: Fatal error: Cannot access protected property SearchApiViewsQuery::$fields in /var/www/html/sarnia4/sites/all/modules/openlayer
So, this should be a different API call, not just hiding it behind a check for an array. I have no idea where to look for proper use of this.
Comment #9
nod_Hi, sorry to switch back to Search API queue but I need confirmation here that what we're about to do is not evil.
The following code in a
views_plugin_style
class crash openlayers when used with Search APISo I made a patch to change to following druken monkey's advice in #1
It doesn't crash anymore but it doesn't look too good. I noticed Search API has a
fields()
method on the query object, should we use it in this case ?The reasoning behind this use-case is that the data is in another display and this one is kind of a placeholder only. I'm not too sure why it's like that but it is for now.
Can you please confirm we're not going to run into issues with Search API if we're using this fix ?
Comment #10
drunken monkeyYou can leave it in your queue, I'm following this anyways.
It doesn't? Normally, this should produce a fatal error when
$this->view->query->fields
isn't accessible.isset($a->foo)
would probably be better (but this is a PHP problem, nothing to do with the Search API).No, that does something else entirely.
Also, you won't be able to „fix“ this for all query plugins in general – so I'd just stick with checking the property and otherwise just living with the query plugin loading unneeded fields.
Comment #11
nod_Great, thank you very much. I changed the queue just in case someone else familiar with search api could answer, not to bother you too much since you already replied earlier.
Indeed there was an isset() in the patch #5, forgot I wasn't in javascript :p
So it's RTBC after all. Thanks again for the confirmation drunken monkey.
Comment #12
zzolo CreditAttribution: zzolo commentedCommitted. Thanks.
http://drupalcode.org/project/openlayers.git/commit/86f7ff2
This needs to go into the 3.x branch.
Comment #13
nod_Merged from 7.x, got the other fixes from a couple of days ago too.
But now I have a warning from views :
Haven't looked closely yet, Any idea ?
Comment #14
mbunyard CreditAttribution: mbunyard commentedI found the Views warnings/notices issue to the located on line 50 of openlayers/modules/openlayers_views/views/openlayers_views_style_map.inc. In the latest development build the code was changed from
to
which allows $this->view->query->fields to be undefined (if not already initialized) when Views attempts to reference $this->fields in views/plugins/views_plugin_query_default.inc. To resolve the issue, I reverted the function to always set $this->view->query->fields to an empty array.
Comment #15
nod_It'll keep on crashing if you use Search API so it's not a solution. So now it's either a Views or Search API issue…
@zzolo: why are we doing this anyway ? I don't get the use-case.
Comment #16
RedTop CreditAttribution: RedTop commentedSame thing occured here on 15 dec 7.x-2.x-dev. Rolled back to beta 1 which seems to work fine.
Comment #17
elly CreditAttribution: elly commentedHeya,
I am getting the same errors in #13 - but not running search API at all on the site I'm working on. Just trying to create a view with a WKT polygon data layer. I believe my view is correctly set up as I have a very similar view working on another site with the same 7.x-2.x-dev version of openlayers. I also have an additional error:
What other modules should I look for as possibly causing this? Could it be a views version or ctools version problem?
Comment #18
jeffschulerI'm getting the following errors in 7.x-2.0-beta1+44-dev when displaying a map via a view:
If I remove the
if (isset($this->view->query->fields))
conditional, I no longer see these...Comment #19
Shawn DeArmond CreditAttribution: Shawn DeArmond commentedI'm now getting the same error as #18. This patch reverts the commit in #12. That fixes it.
Comment #20
batje CreditAttribution: batje commentedI think we are in a loop here. Yes, the error from #18 disappears, but this runs OpenLayers useless if you want to use it in combination with search_api. When you do that, you get
And not in your syslog, but with a WSOD in your apache error.log
Is there any way we can prevent of sites/all/modules/views/plugins/views_plugin_query_default.inc to not fire?
Comment #21
Shawn DeArmond CreditAttribution: Shawn DeArmond commentedHuh. Well, I'm going to move this back to "bug report" and "needs work".
In addition, this should probably be considered a "major" priority, but I'll let the maintainers decide that sort of thing.
Comment #22
thimothoeye CreditAttribution: thimothoeye commentedThis bug has been bothering me for months. Please decide on an appropriate fix.
Comment #23
batje CreditAttribution: batje commentedadded tag
Comment #24
mgiffordIs this a 7.3.x issue or also in 7.2.x?
Comment #25
Slacky08 CreditAttribution: Slacky08 commentedIt seems as if this issue has been fixed in the latest version (7.x-2.0-beta3) - I do not get the protected field error anymore in views.
Comment #26
Pol