I'm not sure if this is a bug, or if I am missing something in how I need to configure this. Basically, when a view gets rendered in a node (using custom PHP call to views "build view" function, or using the insert view module) paging does not work. All nodes are listed in one big list on a single page, even if the standard output of the view (not embedded in a node) uses multiple pages. Any ideas? Thanks!

Comments

merlinofchaos’s picture

merlinofchaos commented

insert_view needs to offer those arguments. If it doesn't this is a...perhaps not bug but a lack of feature in the system.

Also, offering paging in a node can be complex because nodes have automatic paging for comments -- so Eaton, if you implement this be sure to use pager id 1 or higher.

eaton’s picture

eaton commented

merlinofchaos is correct in that insert_view does NOT offer the pager functionality. If I reember correctly, that was an explicit decision because of the inherent complexity of potentially displaying multiple pagers per page.

If it's an absolutely essential feature for insert_view, file a feature request against that project. It's not the fault of views.module :-) I'm pretty busy these days but it will at least be a point for future development to springboard.

bomarmonk’s picture

bomarmonk commented

Is there a way to do this with code? I have used something like this with 4.7:

print views_build_view('embed', $view, array(), false, false);

But this ends up returning the same thing that the insert view module returns. No pagers.

merlinofchaos’s picture

merlinofchaos commented

You should probably at least send through the limit on the $view. Tho actually views should possibly treat a NULL value as 'use the default' rather than unlimited.

You can use the pager but the pager ID issue *can* be a bit sticky. Perhaps if you put the pager ID to use as an argument and explain in the docs that it must be consistent and non-overlapping.

bomarmonk’s picture

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

Thanks for your attention to my issue. I did submit an issue to the insert-view project page, so it will be there if you want to look into it in the future. I think what I will do is simply add some kind of custom block that has a link to the full view (anytime I pull a view into a node). Then I can simply use a limited list (the most current additions) in the view that is embedded.

Still the pager could be a flexible option, even if it is a bit complicated with an inserted view. I'll change this to "won't fix" since an issue is also submitted to insert_view. Thanks again.

merlinofchaos’s picture

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

bomarmonk, it's the false/false that's causing it. If you change the false to '2' (which'll get you pager id #1) and the second false to how many entries per page you want, and you'll get what you need.

bomarmonk’s picture

bomarmonk commented

It does work, but I'm getting many blank pages for some reason. Any idea why changing that number to a "2" generates extra pages in the view? Could this be related to the fact the views are embedded in a node with a duplicate URL alias? I'm just thinking outloud here.

merlinofchaos’s picture

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

Alas I have no idea why you're getting extra pages. It is unlikely to be because you're using the 2. To debug more I'd need to see the queries the view generates.

bomarmonk’s picture

bomarmonk commented

I think I figured this out: basically, these pages were sending invalid view id#'s to the views module, and when the view id was replaced with the proper view, the erroneous pages generated through an invalid view id were left behind. This may have been a cacheing issue-- it seems to have gone away. Sorry that I didn't update this sooner. Thanks for your response. I'll close this.