AJAX responses for views exposed filters broken (worked in beta3)

Ok, I think I have identified the problem. All the data for the openlayers display (layers, features) are in the Drupal.settings object. If the contextual filter was used, the ajax request from views returns the correct number of features.

But in the returned JSON from Views is set, that the settings object is merged. And I think, that is the problem.

0: {command:settings, settings:{basePath:/, pathPrefix:,…}, merge:true}
command: "settings"
merge: true
settings: {basePath:/, pathPrefix:,…}
1: {command:viewsScrollTop, selector:.view-dom-id-a5615b3069e9895ded7f466e6e01c2db}
command: "viewsScrollTop"
selector: ".view-dom-id-a5615b3069e9895ded7f466e6e01c2db"
2: {command:insert, method:replaceWith, selector:.view-dom-id-a5615b3069e9895ded7f466e6e01c2db,…}
command: "insert"
data: "<div class="view view-open-layers-karte-f-r-benutzer view-id-open_layer......."
method: "replaceWith"
selector: ".view-dom-id-a5615b3069e9895ded7f466e6e01c2db"
settings: null

The Drupal ajax handling always merge the Drupal.settings object. See also:

• http://drupal.org/node/1950220
• http://drupal.stackexchange.com/questions/66441/drupal-settings-merging-...

I have now implemented a workaround in my project. Maybe it helps somebody.

With the workaround a new command is returned in the json response from views, that manually reset the features in the layers.

/**
 * Implements hook_ajax_render_alter().
 *
 * Workaround to fix a problem with the ajax response from openlayers
 * views, when the exposed filter was used. See http://drupal.org/node/1993172
 */
function YOURMODULE_ajax_render_alter(&$commands) {
  $features = array();
  foreach ($commands as $command) {
    // Loop over the settings array, to find all features in the openlayer
    // settings.
    if ($command['command'] === 'settings' && isset($command['settings']['openlayers'])) {
      $maps = $command['settings']['openlayers']['maps'];

      foreach ($maps as $map_key => $map) {
        if (isset($map['layers']) && !empty($map['layers'])) {
          foreach ($map['layers'] as $layer_key => $layer) {
            if (isset($layer['features'])) {
              // Reset the features array.
              $features[$map_key] = array(
                'layers' => array(
                  $layer_key => array('features' => NULL),
                ),
              );
            }
          }
        }
      }
    }
  }

  if ($features) {
    array_unshift($commands, array(
      'command' => 'settings',
      'settings' => array(
        'openlayers' => array(
          'maps' => $features,
        ),
      ),
      'merge' => TRUE,
    ));
  }
}

I don't know it really. The ajax return for Drupal.settings will be generated, just before the result will be send to the client, from the Drupal Ajax layer. In the default ajax_command_settings() – that is responsible for Drupal.settings – should not merge. But some piece of code can change this behavior and we have the problem.

Maybe the change is not in the overlay module, but in some other (sub-)module. For example, if somewhere in the Ajax request drupal_add_js() was used, the merge param is always set to TRUE. Thus, the change in the code (between beta1 and beta5) can be very small and have this effect.

My workaround does not solve the problem. He fixes only the negative effect.

Great, I will see what has changed and I will probably find a solution these days.

I'm not using AJAX so I don't spend time on this bug right now.

Fortunately, I'm sick and I have time to kill, so, I might find something by the end of the day ;-)

acbramley,

What you can do to help if you already have your setup, is to replace the submodule openlayers_views from beta3 into beta7 and see if it works.
Don't forget to change the projection id (4326 => EPSG:4326, etc etc), this is really important.

Thanks !

BTW, beta4 was indeed the most broken version, it includes the switch to CTools Export UI and the custom projection stuff from Augustus, I think all of this has really improved in beta7 and we are still improving it :-)

@acbramley Ok. Maybe we have two different issues with a similar behavior.

Hello,

I've spent a couple of hours into this problem and I don't find a working solution, I'm looking for help.
To get help, I've prepared, thanks to acbramley, two drupal installations.

A backup of these installations has been done with drush and you can download them.

First archive: OpenLayers Working Ajax (olaw):

• OpenLayers Version: OpenLayers 7.x-2.0-beta3
• Download: https://docs.google.com/file/d/0B7ugUjBv1lqHYlY1YzNIQjZTakE/edit?usp=sha...
• Restore: drush arr olaw.20130610_144055.tar.gz --destination=/opt/www/olaw --db-url=mysql://root@127.0.0.1/olaw

If you type '2' in the input filter, you'll see only 1 result on the map, which is good.

Second archive: OpenLayers Broken Ajax (olab):

• OpenLayers Version: OpenLayers 7.x-2.0-beta7
• Download: https://docs.google.com/file/d/0B7ugUjBv1lqHYXZVeko1WEc5dFE/edit?usp=sha...
• Restore: drush arr olab.20130610_143636.tar.gz --destination=/opt/www/olab --db-url=mysql://root@127.0.0.1/olab

How to reproduce the problem: If you type '2' in the input filter, you'll keep seeing the 2 results on the map, which is bad, even though, the AJAX response contains only one result (feature).

FYI

• credentials for these sites are admin/admin.
• olaw stands for OpenLayers Ajax Working
• olab stands for OpenLayers Ajax Broken

Just as an update so no one repeats my work:

jQuery('#openlayers-map-b3afa9e9').data('openlayers').map.layers.map_openlayers_1
will get you the layer data for OLAW. I assume the "b3afa9e9" part should be static since we're using these site archives.

jQuery('#openlayers-map').data('openlayers').map.layers.map_openlayers_1
will get you the layer data for OLAB.

I inspected these because I wanted to make sure the issue wasn't with some kind of redraw of the layer. It seems the issue has more to do with the query and the layer that comes back then it does with the map replacement. This is because features array inside the layer data on OLAB has 2 elements whereas OLAW has 1 element. See the attached image.

The next area I'm going to investigate is openlayers_layer_type_openlayers_views_vector::get_features()
I ran a diff on the openlayers_views code in the 7.x-2.0-beta3 and 7.x-2.0-beta7 branches. Looking through the diff, get_features() seems like the most plausible place to start.

If you want to run a diff on these branches

git clone http://git.drupal.org/project/openlayers.git 
cd openlayers
git diff 7.x-2.0-beta3:modules/openlayers_views/ 7.x-2.0-beta7:modules/openlayers_views/

Looks like it's not get_features() because that seems to be returning the same set of features for both OLAW and OLAB.

Cool I can't wait to work on this tomorrow ! :-)

@acbramley, sorry I didn't see all of that stuff and was just working back through it all for my own sake.

@Pol, does the OLAB archive you provided have the openlayers_views files from beta7? I assume it does, but perhaps I should stop duplicating effort...

I recently contacted Geops company (authors of Cartaro distribution) and asked about their possible involvement in solving this issue. The replied, that they would happily do it for a price, which is too much for me. So I would like to find anyone, who will be able to help co-finance this work.

I've spent some time on it. I could not solve yet. By now, I can say:

The problem is NOT in:

• openlayers.js - if you use the file beta3 and replace all ('EPSG:' + by ( it will still display the error.
• function openlayers_views_openlayers_layers() - you can replace this function by beta3.

The problem may be in:

• openlayers_build_map() - in the part which it hanles layer that offers the same projection as the map.
• plugin openlayers_views_vector

Important information

The error is being caused because it is not cleaning up the map features, then it is updating the first result and keeping the second.

There are some extra lines in the OLAB's View:

colordiff view_olab.php view_olaw.php 
73,78d72
< $handler->display->display_options['defaults']['style_plugin'] = FALSE;
< $handler->display->display_options['style_plugin'] = 'openlayers_map';
< $handler->display->display_options['style_options']['map'] = 'map';
< $handler->display->display_options['defaults']['style_options'] = FALSE;
< $handler->display->display_options['defaults']['row_plugin'] = FALSE;
< $handler->display->display_options['defaults']['row_options'] = FALSE;

Hello Weber,

Thanks for your insights! I hope we'll find a solution soon.

This might be a crazy workaround, but seems to work for me at the moment, as for openlayers the good strategy is to always replace the map settings, this will delete the settings before the new settings gets added.

Amazing!

I will wait to get comments from others before committing it :)

@nagy.balint can you tell how did you get to this solution? Maybe it will help to find how the issue is caused.

I discovered this issue last year, and then i spent some days debugging it, and got to the conclusion that it was some kind of a core issue.

Basically the issue seems to be that when you use drupal_add_js for settings then the settings will always be merged no matter what. And in the case of openlayers, where the items on the map are stored in an array, when this merge happens the number of items can only increase but not decrease. In fact the items should be replaced and not merged.

Now the settings mechanism is totally rewritten for drupal 8, but it seems there wont be any change regarding drupal 7 about this issue. One workaround i had in mind included the modification of ajax.js to handle openlayers settings differently. But of course that would have been ugly. But then today i checked this problem again. This problem will occur on all ajax reloads, but currently my goal was to fix the views ajax reload, and so i looked into the openlayers_views module. Saw that it only included one js file, and that the features are added in that js file. So the idea was to clear the features from the settings before the new ones are readded in that js. Because of course even merge is right when the other array is empty.

After that i did a few tests and it seemed to work. Maybe this is not the best solution, but seems to be a fix anyways.

Changing to needs review.

@nagy.balint thank you for the explanation. The part I don't understand is how the old version works in the same Drupal core.

Committed finally !

Thank you very much for your time and work all !