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 |
Comments
Comment #1
kevinquillen CreditAttribution: kevinquillen commentedComment #2
kevinquillen CreditAttribution: kevinquillen commentedFound this bug inside of SearchAPI Views query.inc file:
Line 317:
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:
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 monkeyIt 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.
Comment #4
kevinquillen CreditAttribution: kevinquillen commentedYeah, wasn't sure what exactly it was, I know Views itself is missing docs for the deeper parts of the system.
Comment #5
drunken monkeyPlease see #1368548: Do not index views results by entity id instead – I knew this was already discussed somewhere …