Don't shown in Views

Hi konopko,

I don't really understand why do we need flippy in Views?

We have got pager in Views, could you explain more?

rli,

There are quite a few reasons someone might want a pager in a view. Consider the case where you have a view that just shows the latest of a content type as the front page. It's a one page, unpaged view. You still want to have next/previous links on that view. You could use a views pager, but that falls short on several points. 1) You can't jump to an arbitrary page in the views pager. You can use a contextual filter, but then your pager disappears (as it should) because your view only has a single result. That makes catalog pages and block-based remotes hard. The very simple solution would be to have flippy show in the views (optionally), too. Another answer would be to have both a views pager and flippy, but that's double maintenance, double theming. Which is another thing. The flippy pager is dead simple to theme and really easy to move around in your template files.

So, here's my solution. It works for me. It's incomplete, because it should be optional in the UI (because indeed not everyone wants the pager in their views). I may get to that. It also leads to the question of why menu_get_object (the source of the "problem") is needed at all, since the nid is already available in $vars. Here's a patch:

--- flippy.module.orig  2013-03-10 13:14:53.000000000 -0500
+++ flippy.module       2013-03-10 13:19:09.000000000 -0500
@@ -233,6 +233,8 @@
   // for getting node type
   if ($node = menu_get_object()) {
     $vars['node'] = $node;
+  } else {
+    $vars['node'] = node_load($vars['list']['current']['nid']);
   }

   $label_type = variable_get('flippy_label_type_' . $vars['node']->type, NULL);
@@ -315,7 +317,8 @@
   if (!is_object($node)) {
     return FALSE;
   }
-  return node_is_page($node) && variable_get('flippy_'. $node->type, NULL);
+  //return node_is_page($node) && variable_get('flippy_'. $node->type, NULL);
+  return variable_get('flippy_'. $node->type, NULL);
  }

 /**

Hi fadecomic,

Thanks for your reply.

I have thought about your scenario. But I don't see why I can't jump to an arbitrary page with Views pager. Flippy module is generating the node list by node created time and we can configure Views pager to generate the list in same order I believe.

Please give me a hint if I am understanding wrong.

I'm unaware of how to load a view set to a certain page in the paged view and still have it show the views pager in full. You're right, it's easy to jump to a specific page using contextual filters, but the pager will only page through results that meet those filters. If I created a view of content type X which had 100 nodes, and I wanted to link from a catalog or remote or just a link to node 50. How do I tell the view to go to node 50 by advancing the pager to that page? That is, load the view page, but set the pager the the node with NID 50. I know I can do that with contextual filters, but that will drop the pager as it should because the view now only has 1 page. The problem isn't going to the page, but not losing the pager in the process. If you know how to do it, I would genuinely like to know, because it would be very helpful.

Hi fadecomic,

If we have a view of a content type, say 100 nodes in it. And we set it to 1 node per page. When we are using the Views full pager, we can simply navigate to node 50 by visiting 'MY_VIEW/?page=49'. As the first page will be page 0, we will go to 'target node number - 1'. This is how I navigate to certain node page using the Views pager.

To correct my mistake in previous message, flippy module is not generating the whole node list. All it cares are the 'previous' and 'next' nodes. I am not sure how can we simply use flippy module to navigate to certain node page. Custom pager module is recommended by eaton if we need more advanced function from flippy module.

Hope this can help you.

Right, I realize that that's not the point of flippy. My point was that there are times when it'd be nice to maintain simple previous/next links inside a specialized view. I did notice that you can go to the numbered pages, but the page number only corresponds to NID if your NIDs are consecutively numbered. If I was showing content type "comic" but I'd created a blog page between comic 5 and 6, my NID no longer corresponds to the view page number.

I don't think we need to worried about the nid in the Views pager in this case. If we have a view of 'comic', the pager will exclude blog node from the nodes list. And if we want 'previous' and 'next' links in the View, we can set up the Views mini pager for it. It is pretty much providing the same 'previous' and 'next' link in the view. All we need to do is to theme it a little bit.

I don't think I'm doing a good job of explaining my use case. The requirement for NID is set in stone in this use case. It's coming from elsewhere. You've got, say, a page listing for the comic somewhere. Maybe it's the 3 newest comics in a block somewhere. You need to link this listing to the appropriate comic in the paged view. The block doesn't know about the number of pages in your paged view. It only knows about NIDs (or whatever node specific information). How do you go to the right page in the paged view? The only way I know to do that is using contextual filters. Since that reduces the view results to 1, there is no mini pager. You can't link to a specific page url like MY_VIEW/?page=20 because there is no mapping between NID and pager page number, and your block doesn't know pager page numbers. I mean, I guess you could execute the view programatically and get the number of results to define the links, but that's actually seems to come out to more coding than I did to modify Flippy, and I still have the same pager on both my view and my node, and the flexibility to drop my flippy pager where I like in node--comic.tpl.php. Also, this way, I can throw the flippy generated link for next page around the comic image itself so that clicking the image advances the comic. I'm sure there's probably a way to do it in views, but my argument is that there are cases where you'd want the pager to optionally show in a view.

Yeah, I understand your scenario now. If I have a view with contextual filter which returns one result, I won't have view's pager displayed. In this case we need to display a pager in the view.

However, we need to set up several conditions under which we are allowed to display flippy pager in the Views. Otherwise, we will have flippy pager displayed in every node if our view is displaying more than one node per page. And with flippy pager and the Views pager displayed in the same time will be confused too.

I think this is a feature request rather than bug report. Thanks for all you explanations. We may need to add the flippy configuration in Views setting interface.

Hi konopko,

I see you have managed to add flippy to your node page.
Could explain to me what is your scenario to put flippy in the Views please?

Hi konopko,

The quickest way to make this function working is to set up a mini-pager in your frontpage view, and you may need to theme it a little bit.

Otherwise, please check out Custom Pagers module for displaying in Views as this function has not been available for flippy currently.

Hope this can help.

Hi rli, I just want to note that the Custom Pagers module hasn't been updated since 2011 and a lot of us who are using Flippy now do so because we can't get Custom Pagers to work under Drupal 7.

I managed to work around the Flippy/Views problem by using the Top Node module to create transition pages between a view and my nodes. This allowed me to create hand-coded previous/next links directly to the top node pages, which are able to display the standard flippy pager. It's not a pretty solution but it works for now.

Thanks for your remind ubersoft.

I am thinking to turn flippy into a proper field, which will solve many issues.

And we need to let the maintainer of custom pagers know this issue, as flippy was designed as the simple pager.

Other wise we may need to add custom pagers function to flippy.