Drupal 6.20
Views 6.x-2.12
MySQL 5.0.91
PHP 5.2.17
Apache 1.3.42

Repeatable: Always

Steps to create new content type, test content and view with various pages to list content type entries:

  1. Create new content type test_event with Datestamp field incl repeat options;
  2. Enter 6 test_events with repeat dates, resulting in 75 events (have only tested with same-day events);
  3. Create view to list all nodes of type test_event with nid, title and from-date; page options:
    1. Items to display: Unlimited; Use pager: No; Distinct: No;
      Result: lists all test_events including the repeat dates, 75 in total; (as expected)
    2. Items to display: Unlimited; Use pager: No; Distinct: Yes;
      Result: lists 6 distinct events; (as expected)
    3. Items to display: 10; Use pager: Full; Distinct: No;
      Result: lists the first 10 test_events only, NO pager shown; (unexpected)
    4. Items to display: 5; Use pager: Full; Distinct: No;
      Result: shows 2-page pager only with 5 entries per page, all in all 10 test_events;(unexpected)
    5. Items to display: 6; Use pager: Full; Distinct: No;
      Result: lists the first 6 test_events only, NO pager shown; (unexpected)

Expected result:
Pager is shown in all cases where the total number of test_events is larger than the number of items to display per page (for Distinct=No).

Actual result:
Pager is only shown when Items to display is smaller than number of distinct test_events. In this case the result is also showing only a limited number of items instead of pagers for all 75 entries.

Please let me know if you need any screenshots etc.
Thanks heaps for your help!

Comments

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Closed (won't fix)

If this is true only for repeat dates, then this is probably an issue with that field, not the pager. You should file this against the module providing that field, as per the submission guidelines.

To be fair, repeating events are very, very difficult to do properly.

drumming_cat’s picture

drumming_cat commented

Hi Merlin,

Thanks for getting back to me so quickly.
I actually found out what causes the issue which – as far as I can see – is an incompatibility between the format of repeat-date data and the way Views determines the pager properties.
I think it is hard to assign this as an issue to just one of the projects, so for future reference I have documented below the cause and the hack/change of 1 line in query.inc that I implemented. The hack is BY NO MEANS a recommended hack. However, I could not find an easier way to sort this out myself (not a hardcore programmer) without asking to completely change the way repeat-dates are processed or the way Views is managing the pager.

Cause of the issue

Querying nodes with repeat-date entries results in data which contains a number of rows with the same nid, i.e. the nid of the original node with the date field. This is due to the fact that repeat-dates are calculated based on the original node's settings rather than created as a separate node with its own nid.

When the data is processed for pager display in Views (views/includes/query.inc, 896ff), the following 2 queries are used for creating the pager: query, count_query.

Both queries use the DISTINCT feature. In my example, query contains all fields that I used for the view: nid, title, from-date. Thus, the count of rows from query results in 75 rows due to the difference in from-dates for each entry.

count_query, on the other hand, reduces the number of fields for optimisation and uses only nid, hence results in only 6 rows due to multiple rows having the same nid.

--> This mismatch of rows count causes all the display and pager issues that I described in the original post.

Hack

Alter the query before execution by adding a flag for this particular view to prevent optimization in views/includes/query.inc through a custom module:

function mymodule_views_query_alter(&$view, &$query) {
  if ($view->name == 'test_event_views') {
		$query->do_not_optimize = 1;
  } 
}

Alter views/includes/query.inc in the following way:

910c910
<     if ($get_count && !$this->groupby) {
---
>     if ($get_count && !$this->groupby && !($this->do_not_optimize)) {

(I could not see any way to influence $get_count or $this->groupby for just this view)

This way all my other views with pagers work as before and only test_event_views uses a non-optimized pager query.
I'm sure you could think of other, less nasty ways of doing it. Any recommendations much appreciated!

Cheers, Tash

inversed’s picture

inversed commented

subscribe

mjanouch’s picture

mjanouch commented

Subscribe.

johne’s picture

johne commented
Title: Pager not showing enough pages or not showing at all for CCK nodes with repeat dates » Pager not showing enough pages when multiple copies of nodes to render
Version: 6.x-2.12 » 6.x-2.13
Status: Closed (won't fix) » Active

I've seen this same problem with 6.x-2.13 while not using anything like calendar, event, or whatever other module is mentioned above. In my case, we have a bunch of nodes with multiple taxonomy terms. We display the nodes grouped by taxonomy term. This causes some nodes to display multiple times (under multiple taxonomy terms) Because of that, the number of items to calculate if to display the pager does not always match the number of items to display. The result is the last page of results can be missing a few items. The ndoes are still found by the query built. If those nodes match an exposed filter they will be displayed. But showing all nodes, some number are left off the last page because the pager isn't rendered.

I've tried a variation of what's suggested in #2 and it works for me.

I would suspect this issue also exists with 6.x-2.16 but we had other issues in testing so haven't upgraded yet.

alan evans’s picture

alan evans commented

I'm using 2.16 and the issue still exists. I have a very similar setup to the previous poster - so, my view contains items which might repeat (by nid), but which are grouped within the page such that duplicate nids appear in different groupings (I'm using grouping in views bulk operations). The duplicates are desired and a result of a non-unique nid combined with the grouping field making a unique combination.

As it happens, I did find a way to force the count query to use all fields, but it seems hacky, and I think I'd prefer being able to specify (in a query alter) exactly which fields to use in the count query. Being able to specify not to optimize the count query seems also a reasonable compromise. So, the workaround is you can depend on the fact that any single DISTINCT on any field in the query will make views unable to optimize-away the rest of the fields. You can set this in hook_views_query_alter. Setting distinct on a single field does not mean that it can never repeat in the query result (because there are other fields that make the row "unique" still - distinct only removes entire duplicate rows), but it does force views to not optimize the count query. It's hard to imagine a use case where you need entire row duplicates to show up, but I guess it's possible that one exists. Also distinct could slow down both the count and the main query.

Note that you can't just set distinct on the entire view, as that would add a group-by which will probably nuke any desired duplicates that you have.

chris matthews’s picture

chris matthews commented
Issue summary: View changes
Status: Active » Closed (outdated)

The Drupal 6 branch is no longer supported, please check with the D6LTS project if you need further support. For more information as to why this issue was closed, please see issue #3030347: Plan to clean process issue queue