I use Openlayers with views. I have checked: "Do Not Display Empty Map" and the map is not shown if their is no value, but the view block itself (e.g. title) is still shown. If I change in the same view for example to unformatted list, then the block disappears. So I guess it might be bug in Openlayers. So the view block does not disappear, although I have a filter for latitude return true.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

zzolo’s picture

Hmmmm, I looked at this for a while but could not figure out how to get this to work. I'll have to look at the 2.x version to see if it behaves similarly.

Just to reiterate the issue:

* If no features are found and the "Do not show empty map" is checked, meaning that no map should show, the View is still showing the title (on a block). Testing a normal View block, nothing shows if there is no data.

ckreutz’s picture

Thanks for looking at it. I could not make sense of it and did not check with the 2.x version.

zzolo’s picture

The 2.x version always shows the map, since it does not actually account for the "data" on the map.

I am still not sure how to fix this specific problem. We are rendering nothing, but the view still assumes it has output and therefore is showing the title. Maybe there is some sort of method or property for the view or display that needs to be set (though I have looked at the default code for Views and haven't noticed anything).

tmcw’s picture

In 1.x, shouldn't the map style plugin return nothing if there are no features and the user chooses not to show a map? Currently it does some stuff and returns some stuff:

      // Check if plugin wants to display empty map and if features
      if ($this->options['presets']['not_display_empty_map'] && count($features) == 0) {
        // Ensure regular views ops
        $output .= theme($this->theme_functions(), $this->view, $this->options, '', $group_name);
        return $output;
      }
zzolo’s picture

Version: 6.x-1.0-rc1 » 6.x-1.x-dev

What that is saying is: if we want an empty map if there is no data and there is no data, then we return nothing, but we want to run the process through Views theming in case someone wants to do something special. I remember looking at other plugins and seeing something similar, but I could be wrong.

gmclelland’s picture

I just discovered this myself using the 2.x branch. In addition to rendering an empty map, it also fails to render the "Empty Text" for the view.

zzolo’s picture

Well, again, the 2.x version does not account for data so there is no real way to not display a map. Not sure if there is a real way around this. This means there is no way to display the empty text.

tmcw’s picture

Version: 6.x-1.x-dev » 6.x-2.x-dev
Category: bug » feature

Turning this into a feature request for 2.x. 1.x is no longer developed. However, this is trickier to actually do in 2.x, because a map can show more than one views layer, so is it appropriate to show empty text when one is empty? all? a specific one?

ckreutz’s picture

For me the title is the problem, but I guess with many layers possible in new version the empty text option would be best.

davidhk’s picture

Status: Active » Needs review
FileSize
2.12 KB

Here's a patch that hides an empty map, and shows the view's 'empty text' instead. I think it may have fixed the 'Block still visible without values' problem too, but I haven't tested that.

Three parts to the patch:

1. Add a 'Hide empty map' checkbox at the end of the 'General information' tab for a preset.

2. In openlayers_render_map(), add up the number of features across all layers. If there aren't any features, assume map is empty and return empty string instead of map markup.

3. In openlayers-views-map.tpl.php, don't return anything if there isn't any map markup. (Previously it returned the div, even if there was nothing inside the div. This stopped Views from displaying the 'empty text', and I guess is what caused the block problem too - if there's any text at all present, even an empty div, Views considers the view isn't empty.)

gmclelland’s picture

@gwulo - Patch failed against 6.x-2.0-alpha8. Can you resubmit the patch against the latest version?

I downloaded the patch to the openlayers directory then ran the command patch -p0 < patch-768294-10.patch

(Stripping trailing CRs from patch.)
patching file modules/openlayers_ui/includes/openlayers_ui.presets.inc
(Stripping trailing CRs from patch.)
patching file modules/openlayers_views/views/openlayers-views-map.tpl.php
(Stripping trailing CRs from patch.)
patching file openlayers.module
patch: **** malformed patch at line 60:      $js = array('openlayers' => array('maps' => array($map['id'] => $map)));
zzolo’s picture

Just to let you know, in case you are not aware, all patches should be created and tested against HEAD or the branch HEAD. In this case DRUPAL-6--2. This means checking the module out from CVS. See CVS instructions: http://drupal.org/project/openlayers/cvs-instructions

davidhk’s picture

@gmclelland I'm not using CVS, so to make the patch I downloaded then edited the '6.x-2.x-dev' version from the module homepage. If you try the patch against the dev version (I think that's the same as HEAD that @zzolo mentions), hopefully it will work.

zzolo’s picture

Technically, the dev version is made only once a day so it is not the same as HEAD, but close. Overall this will not cause a problem. But more importantly, it allows you to make patches via CVS with cvs diff -up. Nonethless, we welcome your patches, even if they are not perfect. :)

gmclelland’s picture

Thanks for the responses @gwulo and @zzolo. Learned something new about patching modules.

@gwulo - I downloaded the 6.x-2.x-dev, but unfortunately the patch gave the same output as #11 when I tried to apply it.

I did see the new option and tried to test it anyway, but it didn't work.

Can anybody else test this patch? Seems like an important feature to have.

davidhk’s picture

FileSize
2.06 KB

@gmclelland , I'm still learning how to make patches too, so we're a fine pair!!

Here's the patch file again. I converted it to unix format, which hopefully will stop the messages about trailing CR's. And I've deleted a blank line from the end of the file in case that's the cause of the complaint about line 60.

After applying the patch, do you see these extra lines added to the openlayers.module ?

  if ($map['hide_empty_map']){
    // Check if the map has any features defined. If not, assume it is
    // an empty map and shouldn't be displayed.
    $feature_count = 0;
    $layers = $map['layers'];
    foreach ($layers as $layer) {
      $feature_count += count($layer['features']);
    }
    if ($feature_count == 0) {
      return '' ;
    }
  }

Finally when you say "but it didn't work", do you mean that when the data view returns zero results:
1 A map on a page display is still displayed
2 No Empty Text is displayed
3 The Views Block is still visible
4 something else?

gmclelland’s picture

Here is my output:
openlayers$ patch -p0 < patch-768294-16.patch

patching file modules/openlayers_ui/includes/openlayers_ui.presets.inc
patching file modules/openlayers_views/views/openlayers-views-map.tpl.php
patching file openlayers.module
patch unexpectedly ends in middle of line
patch: **** malformed patch at line 59:

After applying the patch, do you see these extra lines added to the openlayers.module? No

Finally when you say "but it didn't work", do you mean that when the data view returns zero results:
1 A map on a page display is still displayed

This is probably because the patch didn't fully apply the changes in openlayers.module file

davidhk’s picture

FileSize
2.41 KB

I've used a different piece of software to generate the attached patch. Fingers crossed this one applies ok.

gmclelland’s picture

@gwulo - Patch now applies cleanly. -Good job
I tested the all the functionally with my views and it indeed works great. Third time's a charm. :)

I'm not sure if we should change the issue status to "reviewed and tested by the community"?

davidhk’s picture

That's good news - thanks for your patience.

I'm not sure about changing the status either. The handbook says that status means: "The patch has received a thorough review and test by one or more experienced developers, and they have deemed it as ready to be committed to the project. "

What do the module maintainers recommend?

tmcw’s picture

Status: Needs review » Fixed

Thanks gwulo & gmmcelland: Committed: http://drupal.org/cvs?commit=387332
after a quick coder adjustment, shortening the helptext, and making the counting logic safer.

Status: Fixed » Closed (fixed)

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

ano1’s picture

Status: Closed (fixed) » Needs work

Hi,

Unless I am missing something I am still experiencing the glitch that 1st started this thread. When there are no points to display on my OpenLayers block view I do not want the block to display at all.

Here are the steps I followed. I was originally using the 6.x-2.0-alpha10 version of OpenLayers but changed to the dev version to test and make sure the bug has yet to be fixed. I have selected the "Do Not Display Empty Map" option in my OpenLayers preset and left the view empty text field as empty. This correctly hides the map. However, the view itself still does display. The default behavior for views is to not display the view if no results are returned.

As a test I added empty text, the empty text does display, so until I have a solution I have empty text for my block. Any suggestions would be greatly appreciated. I apologize in advance if I have applied the incorrect status to this issue.

ano1’s picture

I have updated to the most recent dev version of the module and am still having the same issue. Is anyone else still having this problem?

TomMynd’s picture

Hi,

I have the same error. The block of the map is rendered even if there is no map to show. When I add "empty text" to the view (the map is currently one layer only) the empty text is displayed.

Currently I have no title and no empty text on the live site with this setup, so there is only a small space for the "empty block".

Can I give any more informations regarding this bug?

Best regards, Tom

zzolo’s picture

Status: Needs work » Active

We currently return an empty string if these conditions are true. There must be a way to designate an empty set in Views, but I do not know what that is at the moment.

elyobo’s picture

Component: OpenLayers Views » OL API

Possibly this is because the views openlayers_map style plugin is defined with "even empty" set to true. I assume that using "even empty" is necessary for some reason, because if I switch it off then I get no views turning up at all, but perhaps there is a better workaround here?

Helge’s picture

Version: 6.x-2.x-dev » 7.x-2.x-dev
Component: OL API » OL Views

If i left my address field empty, the map in my block shows alway the "gun and rod club rd" somewhere in dalaware.
But it schould better show no map or no block.
I have no idea why.

fluffy’s picture

Status: Active » Needs review
FileSize
3.06 KB

This issue is by design, the view always gets rendered by the plugin definition (the "even empty" parameter is set to TRUE). Here is a patch that actually checks for features on the map and then decides if it needs rendering.

Pol’s picture

Excellent thanks ! I'll review it tonight, if it works, it gets in :)

Pol’s picture

Status: Needs review » Needs work

Hello @fluffy,

I created a view with 2 displays.
1 display is a block who display an OpenLayer Map.
1 display is an OpenLayers Data Overlay.

The map displayed in the block is configured to display the Layer provided by the OpenLayers Data Overlay.

When I place the block somewhere, it's lways displayed even if there is no feature on the layer, so I guess but I might be wrong, that the patch is not working as it should ?

Thanks !

fluffy’s picture

Hide empty map should be also ticked in the map settings.

Pol’s picture

Status: Needs work » Fixed

thanks !

Tested and committed !

Status: Fixed » Closed (fixed)

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

GuillaumeDuveau’s picture

Thanks Fluffy !

basvredeling’s picture

Issue summary: View changes

The patch committed from #29 is not correct. It fills the view result with a boolean or a string. But the view result should always be an array. See: #2457303: Wrong type passed to $view->results on empty view