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
Files: 
CommentFileSizeAuthor
#19 openlayers_revert-1340888-19.patch654 bytesShawn DeArmond
PASSED: [[SimpleTest]]: [MySQL] 236 pass(es).
[ View ]
#5 openlayers-views-fix-query-fields-1340888-5.patch654 bytesnod_
PASSED: [[SimpleTest]]: [MySQL] 236 pass(es).
[ View ]

Comments

Project:Search API» OpenLayers
Version:7.x-1.x-dev» 7.x-2.x-dev
Component:Views integration» OL Views

/includes/query.inc

This 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.

Hey @drunken monkey, do you have any tips on how to do this properly in a Views plugin?

Some 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.

I 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.

Status:Active» Needs review
StatusFileSize
new654 bytes
PASSED: [[SimpleTest]]: [MySQL] 236 pass(es).
[ View ]

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.

Priority:Normal» Major

Status:Needs review» Reviewed & tested by the community

I applied this patch and it worked for me.

Status:Reviewed & tested by the community» Needs work

Some 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.

Project:OpenLayers» Search API
Version:7.x-2.x-dev» 7.x-1.x-dev
Component:OL Views» Views integration
Category:bug» support
Priority:Major» Normal

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 API

<?php
 
function query() {
   
$this->view->query->fields = array();
   
$this->view->executed = TRUE;
  }
?>

So I made a patch to change to following druken monkey's advice in #1

<?php
 
function query() {
    if (
$this->view->query->fields) {
     
$this->view->query->fields = array();
    }
   
$this->view->executed = TRUE;
  }
?>

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 ?

Project:Search API» OpenLayers
Version:7.x-1.x-dev» 7.x-2.x-dev
Component:Views integration» OL Views
Category:support» bug

You can leave it in your queue, I'm following this anyways.

It doesn't crash anymore but it doesn't look too good.

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).

I noticed Search API has a fields() method on the query object, should we use it in this case ?

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.

Status:Needs work» Reviewed & tested by the community

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.

Version:7.x-2.x-dev» 7.x-3.x-dev
Category:bug» task
Status:Reviewed & tested by the community» Patch (to be ported)

Committed. Thanks.
http://drupalcode.org/project/openlayers.git/commit/86f7ff2

This needs to go into the 3.x branch.

Status:Patch (to be ported)» Needs work

Merged from 7.x, got the other fixes from a couple of days ago too.

But now I have a warning from views :

Warning: Invalid argument supplied for foreach() in views_plugin_query_default->compile_fields() (line 1070 of /home/theodore/dev/drupal-dev/sites/all/modules/views/plugins/views_plugin_query_default.inc).
Warning: Invalid argument supplied for foreach() in views_plugin_query_default->query() (line 1154 of /home/theodore/dev/drupal-dev/sites/all/modules/views/plugins/views_plugin_query_default.inc).
Warning: Invalid argument supplied for foreach() in views_plugin_query_default->compile_fields() (line 1070 of /home/theodore/dev/drupal-dev/sites/all/modules/views/plugins/views_plugin_query_default.inc).

Haven't looked closely yet, Any idea ?

I 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

function query() {
  $this->view->query->fields = array();
  $this->view->executed = TRUE;
}

to

function query() {
  if (isset($this->view->query->fields)) {
    $this->view->query->fields = array();
  }
  $this->view->executed = TRUE;
}

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.

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.

Same thing occured here on 15 dec 7.x-2.x-dev. Rolled back to beta 1 which seems to work fine.

Heya,

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:

    Warning: usort() [function.usort]: Array was modified by the user comparison function in _openlayers_layers_process() (line 34 of /Applications/MAMP/htdocs/devsite/sites/all/modules/contrib/openlayers/includes/openlayers.render.inc).

What other modules should I look for as possibly causing this? Could it be a views version or ctools version problem?

I'm getting the following errors in 7.x-2.0-beta1+44-dev when displaying a map via a view:

Notice: Undefined property: views_plugin_query_default::$fields in views_plugin_query_default->query() (line 1183 of sites/all/modules/views/plugins/views_plugin_query_default.inc).
Warning: Invalid argument supplied for foreach() in views_plugin_query_default->compile_fields() (line 1101 of sites/all/modules/views/plugins/views_plugin_query_default.inc).
Notice: Undefined property: views_plugin_query_default::$fields in views_plugin_query_default->query() (line 1183 of sites/all/modules/views/plugins/views_plugin_query_default.inc).
Warning: Invalid argument supplied for foreach() in views_plugin_query_default->query() (line 1185 of sites/all/modules/views/plugins/views_plugin_query_default.inc).
Warning: Invalid argument supplied for foreach() in views_plugin_query_default->compile_fields() (line 1101 of sites/all/modules/views/plugins/views_plugin_query_default.inc).

If I remove the if (isset($this->view->query->fields)) conditional, I no longer see these...

Status:Needs work» Needs review
StatusFileSize
new654 bytes
PASSED: [[SimpleTest]]: [MySQL] 236 pass(es).
[ View ]

I'm now getting the same error as #18. This patch reverts the commit in #12. That fixes it.

I 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

[Tue Apr 03 03:42:28 2012] [error] [client 127.0.0.1] PHP Fatal error:  Cannot access protected property SearchApiViewsQuery::$fields in /var/www/devtrac77/sites/all/modules/openlayers/modules/openlayers_views/views/openlayers_views_style_map.inc on line 50
[Tue Apr 03 03:42:28 2012] [error] [client 127.0.0.1] PHP Stack trace:
[Tue Apr 03 03:42:28 2012] [error] [client 127.0.0.1] PHP   1. {main}() /var/www/devtrac77/index.php:0
[Tue Apr 03 03:42:28 2012] [error] [client 127.0.0.1] PHP   2. menu_execute_active_handler() /var/www/devtrac77/index.php:21
[Tue Apr 03 03:42:28 2012] [error] [client 127.0.0.1] PHP   3. call_user_func_array() /var/www/devtrac77/includes/menu.inc:517
[Tue Apr 03 03:42:28 2012] [error] [client 127.0.0.1] PHP   4. views_page() /var/www/devtrac77/includes/menu.inc:0
[Tue Apr 03 03:42:28 2012] [error] [client 127.0.0.1] PHP   5. view->execute_display() /var/www/devtrac77/sites/all/modules/views/views.module:466
[Tue Apr 03 03:42:28 2012] [error] [client 127.0.0.1] PHP   6. views_plugin_display_page->execute() /var/www/devtrac77/sites/all/modules/views/includes/view.inc:1130
[Tue Apr 03 03:42:28 2012] [error] [client 127.0.0.1] PHP   7. view->build() /var/www/devtrac77/sites/all/modules/views/plugins/views_plugin_display_page.inc:215
[Tue Apr 03 03:42:28 2012] [error] [client 127.0.0.1] PHP   8. openlayers_views_style_map->query() /var/www/devtrac77/sites/all/modules/views/includes/view.inc:887

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?

Category:task» bug
Status:Needs review» Needs work

Huh. 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.

This bug has been bothering me for months. Please decide on an appropriate fix.

Issue tags:+searchAPI

added tag

Is this a 7.3.x issue or also in 7.2.x?

It 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.

Status:Needs work» Fixed

Automatically closed -- issue fixed for 2 weeks with no activity.