To reproduce:

1. Create three different Views A,B,C and attach a widget to each, as in the documentation, with the embed style set to inline.

2. Order the blocks A, B, C. The title (set in on the block administration page) will appear for all three, but the content from the view will only appear in C. Rotate to B, C, A. The content will only appear for A. There is no error message in the console, but there is a "failed to load source for [widget views url]" in Firebug.

iFrames don't have this bug. If inline is mixed with iframe, the inline still has to be at the bottom, or it will not appear.

(My use case is taking recent posts and comments from one sibling site to another, and putting them in the sidebar. Inline is exactly what I need, since (a) iFrame puts scroll bars in if there is vertical overflow, and (b) inline doesn't respect the vertical dimension at all.)

Thanks for a great module otherwise!

Comments

shunting’s picture

Drupal 6.14, php 5.3.2, FF 3.5.15.

UPDATE Adding... This isn't a theming issue; it happens with my custom theme, but also with Nitobe.

_vid’s picture

@shunting, I just stumbled onto your issue as I was looking into using this module and the problem sounds familiar.

When dealing with multiple view displays in the past I've noticed that if any of the displays are a 'page' you'll see a title and content override on any other displays that are run on the same node.
I haven't looked at this module's code but perhaps this will help.
http://drupal.org/node/131031#comment-3667720

Maybe the webwidget display is similar to a page display and doesn't operate as you might expect when more that one appear in the same node.

tobby’s picture

Status: Active » Needs work
StatusFileSize
new3.26 KB

What's happening (at least in my case) is that the javascript is using window.onload = function()... to trigger the display of the widget. Every time a widget is parsed on the page, the window.onload object is overwritten with the new function, so only the last one on the page will fire.

This will also interfere with anything else on the page that uses that; possibly ad code or local/custom javascript.

Additionally, the widget code uses the widgetContext variable to contain the ID of the target div. This also gets overwritten with the last widget that displays on the page. My solution was to rename this variable to something unique per widget so that it will be unique enough on the page (see my warning below).

I've created a patch for the 7.x version of this module, but the same solution should work for 6.x as well, since it's really a javascript fix.

CAVEAT: This will break any existing widgets in use, since the responding javascript that contains the actual widget content will no longer look for the widgetContext variable. I haven't come up with a solution for that yet. So, use this patch with caution.

febbraro’s picture

Version: 6.x-1.4 » 7.x-1.x-dev
jec006’s picture

Status: Needs work » Fixed

Committed to 7.x-1.x

jec006’s picture

Status: Fixed » Patch (to be ported)
clemens.tolboom’s picture

Version: 7.x-1.x-dev » 6.x-1.4

Moving to 6.x

pierrot’s picture

Made this patch work on the D6 version.

Just had to change

$variables['id_suffix'] = substr(md5(request_path()), 0, 12);

to

$variables['id_suffix'] = substr(md5($_GET['q']), 0, 12);

in the template_preprocess_web_widgets_inline_wrapper() function since request_path() is D7 only.

Had also to change

$path = substr($path['path'], 1);

to

$path = $path['path'];

in the template_preprocess_web_widgets_inline() function. With the first character cut, the id_suffix weren't matching between the inline.tpl and inline_wrapper.tpl.

However thanks a lot, you saved my day!