Installing the Views Distinct module causes odd behaviour for Views Slideshow module on CSS level. I do not know the exact cause of the problem, but it restructured html completely (e.g. widget pager). Uninstalling the module solved the problem. Does Views Distinct use similar classes?

CommentFileSizeAuthor
#3 views_distinct-skip_rerender_if_no_output_change-1956878-3.patch2.68 KBjay.dansand
#2 select_distinct_gd.JPG53.51 KBmarksmith
#2 select_distinct_wr.JPG58.2 KBmarksmith
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jay.dansand’s picture

jay.dansand CreditAttribution: jay.dansand commented
Assigned: Unassigned » jay.dansand
Status: Active » Postponed (maintainer needs more info)

The simple answer is Views Distinct doesn't use any CSS classes, or any HTML markup directly. Are you setting it to aggregate or filter duplicates? And, is the field set to "Filter/Aggregate based on the rendered value"? That option changes HTML, but only by combining rendered HTML with the given separator (default ",").

Can you describe the odd behavior?

marksmith’s picture

marksmith CreditAttribution: marksmith commented
FileSize
select_distinct_wr.JPG58.2 KB
select_distinct_gd.JPG53.51 KB

The odd behaviour appears once the module is installed, that is without even starting to use it (filter or aggregate) in any views. I attached two screenshots to see the difference without (select_distinct_gd.jpg) and with (select_distinct_wr.jpg) the views_distinct module installed.
Thank you for your answer.
ms

jay.dansand’s picture

jay.dansand CreditAttribution: jay.dansand commented
FileSize
views_distinct-skip_rerender_if_no_output_change-1956878-3.patch2.68 KB

I think I have half of the issue solved - I changed how the hook_views_post_render() function works so it should not affect any view where Views Distinct + "Use the rendered output of this field" isn't used.

There may be an additional compatibility issue with the post_render aggregation and Views Slideshow when the View is re-rendered; I'll have to look more deeply into that. Still, this patch (also committed to the 7.x-1.x-dev branch) should at least prevent any issues if you are not using Views Distinct + post_render in the Views Slideshow view.

marksmith’s picture

marksmith CreditAttribution: marksmith commented

Thank you, Jay. Unfortunately the problem has not been solved by this update. The same behavior occurs after re-installing and enabling the new dev version of the module.
ms

marksmith’s picture

marksmith CreditAttribution: marksmith commented

Now I think I have found something here! Although I do not know why it happens, but this is what I observe on the CSS level.
When the views_distinct module is enabled (but prior to being implemented in any views) the div id-s of the original Views Slideshow are altered, the original id being appended by a _2. So for example #views_slideshow_cycle_main_news-block_2 is changed to #views_slideshow_cycle_main_news-block_2_2, #widget_pager_bottom_news-block_2 is changed to #widget_pager_bottom_news-block_2_2. I hope, Jay, this will help you figure out the exact cause of the problem.
ms

jay.dansand’s picture

jay.dansand CreditAttribution: jay.dansand commented
Status: Postponed (maintainer needs more info) » Active

That definitely does help, thanks! I'm swamped today, but I'll try to look at it early next week.

jay.dansand’s picture

jay.dansand CreditAttribution: jay.dansand commented

Quick update: it looks like the "_2" suffix is being appended by Views Slideshow in "theme/views_slideshow.theme.inc" in function _views_slideshow_preprocess_views_slideshow():

function _views_slideshow_preprocess_views_slideshow(&$vars) {
  // ...
  // Give each slideshow a unique id if there are more than one on the page.
    static $instances = array();
    if (isset($instances[$vss_id])) {
      $instances[$vss_id]++;
      $vss_id .= "_" . $instances[$vss_id];
    }
    else {
      $instances[$vss_id] = 1;
    }
  // ...

It's $vss_id that ends up becoming "example_2", because Views Distinct calls $view->display_handler->render() a second time when post-rendered filtering is used. I don't know how to avoid doing that, but I'm investigating it.

I wasn't able to get this behavior to manifest without enabling Views Distinct on that View, though. I had to go into the fields on the slideshow view and enable Views Distinct w/"Use the rendered output of this field" checked. As far as I can tell, the latest dev (and the patch in #3) should have solved that part of the issue, anyway. If you're still observing this on views without Views Distinct enabled on the view, I'd be grateful for more information, because I haven't been able to replicate that.

jay.dansand’s picture

jay.dansand CreditAttribution: jay.dansand commented
Status: Active » Closed (cannot reproduce)

The following caveat has been added to the KNOWN ISSUES section of the README.txt and project page for a couple of months now:

Potential incompatibility with some style plugins: The "Use the rendered output of this field" option in Views Distinct may cause odd things to happen with some style plugins that change output when called twice (e.g. Views Slideshow - see #1956878: Interference with Views Slideshow). This is because Views Distinct needs to re-render the rows when it makes changes to the View output after the fields have been rendered. If you encounter this issue, uncheck the "Use the rendered output of this field" option.

I have not been able to reproduce the problem described here: manifesting the error even when "Use the rendered output of this field" is turned off.

I'm closing this issue as "cannot reproduce" for now; please re-open if you are still encountering this problem with "Use the rendered output of this field" disabled. Thanks!