SemanticViews row classing breaks under SearchAPI [#1623448]

I am not sure if this is a SemanticViews/Views problem or SearchAPI Solr.

I have a Solr based View being rendered with SemanticViews. I am using the option of every nth row to receive a particular class. However, looking at the source, the classes are never added in the correct order. All other views that are not Solr based are classed correctly. This is the only one that is not.

Is there something about Solr index results that will prevent this from happening? I don't have any sorting in Views (but would like to use them). I did notice that searching solr indexed content without any filters, the rows appeared to class correctly. As soon as I filter it down, the row classes go out of whack.

Ex. classes should look like this:

 - row1
   -- item-first
   -- (none)
   -- item-last
- row2
   -- item-first
   -- (none)
   -- item-last

Instead I see:

 - row1
   -- item-first
   -- item-last
   -- (none)
- row2
   -- item-last
   -- item-last
   -- (none)

except the second example above is randomized...

Comment	File	Size	Author
#3	1623448--start_views_row_indexes_at_0-3.patch	538 bytes	drunken monkey
#3

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

kevinquillen CreditAttribution: kevinquillen commented 19 June 2012 at 13:23

Project:	Search API Solr	» Semantic Views
Version:	7.x-1.0-rc2	» 7.x-1.x-dev

Comment #2

kevinquillen CreditAttribution: kevinquillen commented 20 June 2012 at 19:19

Title:	SemanticViews is not classing rows correctly	» SemanticViews row classing breaks under SearchAPI
Project:	Semantic Views	» Search API
Version:	7.x-1.x-dev	» 7.x-1.1
Component:	Code	» Plugins
Category:	support	» bug

Found this bug inside of SearchAPI Views query.inc file:

Line 317:


foreach ($rows as $id => $row) {
      $view->result[$id] = (object) $row;
    }

When using the nth row classing of Semantic Views, it won't add the classes properly at all since each row is starting with the result row ID instead of from 0 every time. When you perform searching/filtering on a View, this is noticible when laying out images for example in a grid layout.

I did this to alleviate the issue:


foreach ($rows as $id => $row) {
      $view->result[] = (object) $row;
    }

This made the query result start from 0 each time, which allows Semantic Views to count the rows proper and class them on nth row option.

I am not sure what this may impact from removing the $id, but it corrected my display issue.

Comment #3

drunken monkey

he/him

German

Vienna, Austria

CreditAttribution: drunken monkey commented 21 June 2012 at 19:02

Status:

Active

» Needs review

File	Size
1623448--start_views_row_indexes_at_0-3.patch	538 bytes

It cannot really be called a "bug" if Search API deviates from Views' undocumented expectations, but as a lot of plugins seem to struggle with this I guess we should try to fix this. (Since the Views integration is pretty complicated, I previously hesitated to avoid breaking something in a complicated way.)

Attached is a patch implementing your suggestion. As you say, it doesn't seem to break anything, but I'd be glad if some more people could verify this.