I'm using views_cycle.module which renders 'thumbnails' for the cycler using a field of your choice. There is a loop in the module's code that contains the line:
$vars['thumbs_data'] .= "<li class='{$classes}' >". $view->render_field($options['thumbnail_field'], $num) ."</li>";.
As of views-6.x-2.7, if the chosen field is the global counter, i.e. $options['thumbnail_field'] == 'counter', the return value is always the total number of rows rather than the current row, regardless of the value of $num in the above line.
To put it another way, if I am outputting 3 rows in my view, $view->render_field($options['thumbnail_field'], $num) always returns 3. The thumbnails render as "3 3 3" rather than "1 2 3."
I could be wrong but this seems like unintended behaviour from views.module rather than something that needs patching in views_cycle.module.
Comments
Comment #1
dawehnerCan you please try to use the dev version, i think there was something fixed there.
Comment #2
morbiD commentedOh, I forgot to say, I already tried the dev version hoping it was fixed, and got the same problem but with the count decreased by 1.
So, in 6.x-2.6 my thumbnails read "1 2 3" as they should.
In 6.x-2.7 they read "3 3 3."
In the current 6.x-2.x-dev they read "2 2 2."
Comment #3
dawehnerCan you please export your view? Then i can have a look at
Comment #4
morbiD commentedHere you go:
Comment #5
dawehnerI guess you should use the dev version of views_cycle see http://drupal.org/project/cvs/408888
Move to views_cycle issue queue
Comment #6
morbiD commentedSorry. Please forgive me if I am misunderstanding the way the issues tracking system works, as I have never reported a bug before, but why move this to the views_cycle queue?
Both the global results counter field and the render_field() function are components of views. views_cycle merely makes a call to render_field() which works perfectly when passed any field name, except the global counter which stopped working with the latest release of views, when I believe a patch to views_handler_field_counter.inc was committed.
If the bug is in views, how will moving the bug report to views_cycle help fix it?
Also, I'm already using the latest dev version of views_cycle as suggested. Indeed, I notice the views_cycle CVS message:
Switch from ->theme() to $view->render_field() in the preprocess function, per recommendation from merlinofchaosso it's not like views_cycle shouldn't be using render_field(). The combination of render_field('counter', $row) is just broken.Do correct me if I'm looking at this the wrong way, of course.
Comment #7
morbiD commentedI see the root cause of this now. The render() function in views_handler_field_counter.inc does absolutely nothing with objects passed to it, so it is seemingly impossible to request the count for any specific row.
The count gets incremented when views builds each row, and once the last row has been built the count remains at that final value. Thus, other modules can only get the count for the last row.
Comment #8
morbiD commentedComment #9
merlinofchaos commentedNote that as of Views 2.7 all the fields are now pre-rendered for the style, which is probably the problem here. The problem is that with this change, you're not rendering a field a second time, which is unnecessary.
The style can get its fields off of $fields = $this->rendered_fields which will get all of the fields that were rendered. This was necessary to make certain substitutions work.
Comment #10
Crell commentedHm, someone forgot to tell me about that change in 2.7. :-) I've updated views_cycle to use ->rendered_fields, and I think it's working now (as of the latest dev). If not, please open an issue in the views_cycle queue.